Seeking feedback! #BI #Bigdata #Analytics #PMOT

Based on our study from 2017, we built a classification model for Business Intelligence and Big Data Analytics projects. We would be interested in how well the model classifies your project, and if the reporting information is relevant for project management. You can select “generate report” and provide your project specifications at the following site: http://bit.ly/2qRdzG2 .

Let us know your feedback.

In addition, on the following dates, we will discuss the study results in our office in Heidelberg, Germany. Please contact us if you wish to join.

  • Success Criteria for BI and Big Data Projects: Friday, 30.11.2018
  • Stakeholder Influence on System Use and Success for BI and Big Data Projects: Friday, 25.01.2019

2. PM Stammtisch: Impact of Multidisciplinary Teams and Data Scientist on Project Success

In the Project Management Stammtisch on the 26th of October, we covered “Impact of Multidisciplinary Teams and Data Scientist on Project Success Project Management Stammtisch. ”

The research in this area offered an intriguing story about teams and individuals. The profiles of the participants were of mixed: An Artificial Intelligence specialist managing international projects, an Agile Coach, Scientific Journal Editor…Nevertheless, the group came to a similar conclusion: having specialist in the team is important for learning, building a well-functioning team with mixed profiles is important to success.

We used the session as an opportunity to announce the availability of a system to generate a custom target project planning report. https://www.pmxtra.com/dspcsf/Index.php.

DSP Entry Screen
DSP Entry Screen

1. PM Stammtisch : Project Success Factors for BI and Big Data

In the Project Management Stammtisch on 28-September, we covered the topic “Project Success Factors for Business Intelligence (BI) and Big Data.”

The discussion was on a comparative analysis of Big Data Analytic and Business Intelligence projects from our project success study. In short, the study compared 52 demographic and project attributes. None of the organizational demographic (e.g., industry, organization size) or project demographic or efficiency factors (e.g., team size, budget, duration) items were significantly different. Also, business strategy, top management support, and client acceptance were not significantly different. Of the 39 remaining items, 18 were significantly different all in favor of Big Data Analytics. This information reflected the discussion of the session participants. Especially interesting was the role of Senior Managers in the success of the projects. The participants reflected that Senior Managers could act as a buffer between the project and top management to ensure the project maintains an agreed course of action until a successful outcome is reached.

The following diagram reflects the differences in the project complexity, pace, technology uncertainty, and product novel between Big Data Analytic and Business Intelligence projects. Complexity and product novelty were significantly different. The diagram is based upon the Diamond model for project success from Shenhar, A., & Dvir, D. (2007).

Figure 1: Project Attribute Comparison

You can find a conference paper on the study comparison at the following location: https://annals-csis.org/proceedings/2018/drp/pdf/125.pdf.

References:

Shenhar, A., & Dvir, D. (2007). Reinventing project management: the diamond approach to successful growth and innovation. Boston, Mass.: Harvard Business School Press.

Miller, G. J. (2018). Comparative Analysis of Big Data and BI Projects. Paper presented at the Proceedings of the 2018 Federated Conference on Computer Science and Information Systems. http://dx.doi.org/10.15439/2018F125

Benchmark : BI, BigData, & Analytic Project Success

Based upon our Decision Support Project Survey, we have created a template for a benchmark comparison that can be used to share best practices or identify areas of improvement.  The survey analyzed 78 projects for critical success criteria and factors and created a classification model. The classification model has been documented and peer reviewed by members of the Computer Science and Information Systems community. Based on the model, the classification of the project is given and comparisons are made to other respondents from the survey

Figure 1: Decision Support Projects Benchmark Comparison

In our PM Stammtisch, we will present the results of the study and discuss how the results can be used in practice.

  • Success Factors for Business Intelligence (BI) and Big Data Projects: Friday, 28.09.2018
  • Impact of Multidisciplinary Teams and Data Scientists on Project Success: Friday, 26.10.2018
  • Success Criteria for BI and Big Data Projects: Friday, 30.11.2018
  • Stakeholder Influence on System Use and Success for BI and Big Data Projects: Friday, 25.01.2019

Survey results: BI, BigData, & Analytic Project Success

The aim of the research was to understand the success criteria for decision support projects and what influences the performance of those projects. “Decision support projects are implementation projects that deliver data, analytical models, analytical competence, or all three, for unstructured decision-making and problem-solving. They include subspecialties such as big data, advanced analytics, business intelligence, or artificial intelligence” (Miller,2018).  This report summarizes the survey inputs from and analysis from 78 projects. The first section provides descriptive statistics for the data that was collected as part of the survey. The second section provides summary of the analysis that was performed with the survey data.

Demographics

The majority of the projects were undertaken as internal projects by large organizations, with big teams and networks of involved organizations. They were diverse in terms of complexity, pace, novelty, and team structure. The participants were from 22 countries with 73% being based in Europe.

Project Classifications

Analytic competency and building analytical models and algorithms are characteristics that differentiate the decision support project types.

Critical Success Factors

System quality and information quality are critical success factors that influence system usage and system usage influences project success. Project schedule and budget performance are not correlated with the other success measures so they are not critical success factors in most cases.

Figure 1: Interactive chord diagram of variable correlations

Stakeholder Contribution

Business user, senior manager, top management, and data scientist participation in project activities such as requirements and model building is a benefit. It increases the chances of achieving organizational benefits months or years after the project has been completed.

Bottomline

The recommendation is to actively engage business users and senior managers in hands-on project work such as building models and to focus on providing sufficient system and information quality.  As a consequent, the project should deliver long term organizational benefits.

Next Steps

On the following dates, we will discuss the study results in our office in Heidelberg, Germany. Please contact us if you wish to join.

  • Success Factors for Business Intelligence (BI) and Big Data Projects: Friday, 28.09.2018
  • Impact of Multidisciplinary Teams and Data Scientists on Project Success: Friday, 26.10.2018
  • Success Criteria for BI and Big Data Projects: Friday, 30.11.2018
  • Stakeholder Influence on System Use and Success for BI and Big Data Projects: Friday, 25.01.2019

Free “Going Agile” ePub for PM / BigData /Analytic / BI survey input by 1-Oct http://bit.ly/2jRUhzx

I am doing some research to investigate success from a project perspective of the different types of decision support projects and their contribution to organizational performance. Join the effort and get a free “Going Agile Project Management Practices Second Edition” ePub or Kindle book (worth 32 USD on amazon).

Project managers, agile coaches, project team members, and sponsors that participated in a big data, business intelligence, or analytics project since 2002 can to take the survey. http://bit.ly/2jRUhzx

So far, people from 14 countries have contributed. Regards, Gloria

Building a Team with Collaborative Events

The agile coach has the responsibility to build the team into a self-organizing unit that can make its own decisions and resolve its own conflicts as well as collaborate as a team to deliver the product. Building a team is much more than building a working group. ‘Going Agile – Project Management Practices’ says the agile coach has to

  1. form the team and develop it through different stages,
  2. build collaboration amongst the team members,
  3. set the framework for group decision-making, and
  4. facilitate conflict resolution.

He or she has to take a newly formed group of individuals from individuals working together, which would be a ‘working group’, to a team. Teams go through stages of development and they tend to reach their best performance after having been established for a while. Bruce W. Tuckman identified four phases of development concerning interpersonal relationships and task performance:

To ensure the team members are clear about the project goals, the agile coach should use a collaborative event such as the chartering session, and create an environment that allows the team to collaborate in the creation of the product. Collaboration is two or more people or organizations working together to realize shared goals.

Collaboration event – Planning session

The diagram is for a project planning and estimation session. It was developed together with project team members and the client. It was used in the forming stage of the project. It supported alignment of team members towards the project goals and with one another, and a cross understanding of project tasks that needed to be completed. In the opinion of the project manager, it reduced the duration of the storming phase.

At the top of the diagram are hand drawn boxes that would represent phases in the project. Going from an initial deliverable in the first column and to building successive components until the final product on the right side. Wide-band estimation according to Fibonacci numbers suggested by Planning Poker ® were used.

The components of the diagram are:

  • The sticky note (yellow and pink) represents the tasks that have to be completed.
  • The color represents if the tasks could be completed by the project team (yellow) or if it was sourced from a third-party.
  • The tabs represent the estimates for the task.
  • In the lower left is the legend for what colors represent what levels of effort.
  • Each post-it® received an estimate if possible.
  • If it was not possible to estimate the effort, the task was placed in the box in the lower right corner.

According to the visualization recommendations, the design of this visualization fits the recommendations.

  1. Make it action-oriented:  Created during the session; retained as reference during the project
  2. Make it messy: the order developed during the session and its ugliness was retained
  3. Make it specific to the situation — It was for a specific project.
  4. Use different dimensions — it uses different…
  • Position:  represents the evolution of the product over time
  • Colours: pink, yellow, green
  • Shapes: oblong post-its are tasks; tabs are estimates
  • Numbers: are used as estimates

5. Make it interesting – the team was motivated and engaged.

 

Visualization in Projects – User Roles and Personas

Agile methodologies suggest the use of user stories that are specific to a role. Personas are one way of representing these roles.

User Story

As Gloria J. Miller writes in “Going Agile – Project Management Practices” the format for user’s story should include a title and the information on the role of the user, the function they need, and the value they should derive from the function. The following is the type layout of the user stories.

As a <user persona> I want to <function; what they want to do>

so that I can <business value; why they want to do>.

A Role defines the characteristics of typical users for the system. It should be represented by a persona or an extreme character. A ‘persona’ is an imaginary representation of a specific user role or ideal customer, a sort of a “prototype”. Personas should be created based upon market and demographic research to ensure the persona represents the target audience or user. It is about focusing on the major needs of the most important user groups. One user can’t be everything to everyone.

A function describes the capability that the user requires. The function should finish with the completion of an activity and not an on-going activity. For example, “as a webmaster I want to manage a website” is something never ends. “As a webmaster, I want to add and delete web pages” is a task that can be checked as completed. Business value explains the importance of the function or the value it derives.

Persona Visualization

A persona visualization that can be used in projects is to create a poster or chart with the personas that are relevant for the system under discussion. The following visualization is an example used in a previous project.

 

Based on the article a few recommendations for visualization practices in projects, this visual aid fits the recommendations as follows:

  1. Specify your objective for visualization —
    • Deciding and scheduling who got what level/content of training;
    • Setting-up the role and security concept for the system;
    • Making design decisions about who could perform what tasks in the system.
  2. Make it action-oriented — used to facilitate discussions, meetings and design decisions
  3. Make it messy — N/A
  4. Make it specific to the situation — It was for a specific project.
  5. Use different dimensions — it uses different…
    • Position of the persona – was based on organization hierarchy and functional role
    • Role – system end-users’ role
    • Photos/Avatar – real people with whom details could be discussed
    • Text – describing activities that people would need to do with the system
  1. Make it interesting —

Overall, personas are crucial throughout the entire system or product development phase and should be real-life representation. They are vital to launching a useful and usable system or solution.

Project Visualization: Sankey Diagram of Project Effort – by Gloria J. Miller

Sankey diagram is a data visualization tool that can be used to visualize multidimensional data in different ways. Originally, they were used to visual the flow of resources such as energy or material. The important features of Sankey diagrams is that they represent the physical flow from a source to a target related of a unit of measure (e.g., functional unit or period of time) and that the magnitude of the flow is shown by the size of the link. (Lupton and Allwood, 2017)

For project management, Sankey diagrams can be used to show the flow of effort between such topics as companies, roles, and deliverables. The diagram is a Sankey diagram of actual effort for a technology implementation project. It shows how the total project effort is divided by different dimensions (i.e., company, role, deliverable, and capability) and how the effort flows between the different dimensions.

Based on the article a few recommendations for visualization practices in projects, this diagram fits the recommendations as follows:

    1. Specify your objective for visualization — Demonstrate how effort was spent within the project.
    2. Make it action-oriented  — Not action oriented in print; online each flow can be selected separately and the value of the flow is shown in a tool tip
    3. Make it messy — N/A
    4. Make it specific to the situation  this was the real history of the project.
    5. Use different dimensions — it uses different…
      1. colors, which show effort different sources and targets
      2. size, flow size is relative to amount of effort
      3. Dimensions: based on columns
        1. Company
        2. Project role
        3. Deliverable
        4. Capability
  • Make it interesting — visual way of evaluating project effort
How it was created

The diagram is based on the timecard entries for a specific project considering 1) the person, 2) the roles the people fulfilled, 3) their company. 4) hours worked, and 5) a comment associated with the time entry. The comments were analyzed and assigned to a deliverable and to a capability. The effort was summarized for a three-different source and target columns as follows.

List Source Target
1 Company Role
2 Role Deliverable
3 Deliverable Capability

All three summaries were put into one csv file and visualized using d3js Sankey java script. An example of the csv layout is as follows.The source code for java script at the following location.http://bl.ocks.org/d3noob/c9b90689c1438f57d649

Reference:

Lupton, R. C. & Allwood, J. M. 2017. Hybrid Sankey diagrams: Visual analysis of multidimensional data for understanding resource use. Resources, Conservation and Recycling, 124, 141-151.

Project Visualization: Retrospective Review

Recently, we published a few recommendations for visualization practices in projects, so let us ‘visualize’ these recommendations through this board.

Any identifying objects for the project or the customer are removed from this version

The first time I saw this picture was in a project retrospective review meeting. I thought “are we playing a game?” It was actually a board in form of a snake, although not for playing, but rather for visualize what happened in the project we had just finished. It was used as a facilitation tool in a lessons-learned session with the core team members from the project. According to our recommendations from the last article:

  1. Specify your objective for visualization  This board was part of a retrospective review to discuss the project history, what happened, and what lessons we learned along the way.
  2. Make it action-oriented — In the review session, we used post-it’s to discuss what to change in the playing fields.
  3. Make it messy — Although it was printed, we were encouraged to change whatever we wanted.
  4. Make it specific to the situation — This was the real history of the project with the actual events that occurred.
  5. Use different dimensions — It uses different…
    • colours, which show effort estimates by week (e.g. black = less than 3 person/day in a week; green = 9-17 person/day in a week).
    • shapes, e.g. block is a week.
    • numbers, which are the weeks in the year (calendar)
    • symbols, which show activities when they occurred
      • inside the blocks = events (e.g. installed the server).
      • outside the blocks = risks (danger sign), holidays, collaboration.
  6. Make it interesting — this is obviously something subjective, but for me this board was catchy and it attracted attention.

The objective of the meeting was to discuss what went well, what went wrong (and why) and what could we have done better. The main idea here was still the act of discussing, communicating with each other as free as possible. This board was an efficient aid for visual communication that encouraged us to evaluate and measure in a comprehensive way.

You can find the template for the board at the following location: http://boardgames.lovetoknow.com/Blank_Board_Games_to_Print