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

Can we Motivate you to Share your Knowledge?

Knowledge Management (KM) implies creating, using, sharing and managing the knowledge of people from an organization. Some of the benefits of supporting the processes of KM are clear and well-known. The PMBOK(R) Guide 6th edition adds the chapter 4.4.2. “Manage Project Knowledge: Tools and Techniques” in recognition of KM importance.

KM is about people, processes and technology so it should support people and make their work-life easier. It is important for:

  • avoiding reinventing the wheel

  • reusing documents and ideas

  • taking advantage of experienced employees and their expertise

  • avoiding making the same mistake twice

  • rewarding through a nice recognition system

About How Technology Changed People and Organizations

In the past, when you knew how to do or make something you would share your know-how with family, friends and neighbors in a natural and easy way. It could be how to paint a wall, how to cook a certain dish, how to repair a shoe or anything you can imagine of. Elderly people had more experience and expertise and were happy to share it with the younger generations. It was their purpose in life.

When did this purpose of life change? Was it when the Information Technology started to dominate the world? It probably was. Nowadays elderly generations are often no experts in new technologies. It is rather the younger ones who teach the older ones how the new technologies work. Is this generally applicable to the employees of an organization? Don’t people from previous generations have more experience that could be also useful? How can we make sure that the technology works for all the people and not vice-versa?

Using IT-driven KM can be a double-edged sword. Technology connects those who have the expertise with those who need it when they need. It opens doors for communication and information exchange across organizational and geographical boundaries. But, does it also facilitate exchange of knowledge? Technology can also close doors when it comes to sharing knowledge. If the technology is too complex or requires too much time and effort, then it is more a barrier than a help.

About Creating a Knowledge Sharing Culture

Many organizations struggle to run effective KM processes. ‘Knowledge’ on its own is related to a person and his/her ‘know-how’, his/her ability doing something or his/her expertise on a certain topic gives him/her a certain power.

It is crucial to create a culture that supports knowledge sharing and re-use. Making people understand that knowledge sharing can benefit them personally through examples of how they can improve their performance is the base of this culture. Putting the own experience into words or writing it down is extremely valuable. The face-to-face exchange of experience can happen in a formal way such as in a meeting or a workshop or less formal such as at a coffee corner.

In order to create such a knowledge sharing culture, this should be supported by all the departments and be part of the job requirements. In my experience as a former administrator of a KM system, colleagues often said they had no time to complete any KM process, they were too busy. Normally they mean it is not a priority. Including it in job descriptions and using it in appraisal programs would support KM culture to a large extent, and would make everyone spend time on sharing their knowledge.

It is popular to share best practices, but not to share ‘worst practices’. Even though you would probably learn more from what-went-wrong than from what-went-well. These ‘lessons learned’ would provide some essential learning, no matter what generation you belong to. We should celebrate mistakes in order to avoid making the same mistake twice.

About the Process of Motivating People

Many people think they become dispensable when they share what they know, what they learned while managing a project. How can we motivate employees to share their knowledge and expertise? Somebody with wide project management experience said: “You cannot motivate them, you have to force them”. I agree only partially. I have seen that colleagues shared their knowledge for three reasons:

  1. If they were forced as it was part of their performance plan (e.g. bonus),
  2. If they received positive feedback from their contribution
  3. If they felt they were recompensed. Recompense does not have to be monetary, but moreover in form of recognition and value: Public recognition, acknowledgment, a symbolic prize, or a voucher.

You only become dispensable when you stop adding value to the company, when you stop learning, when you don’t feel being part of something.

Sharing knowledge is still a challenge for many organizations. It is the human nature to love having power. Since knowledge is power, it remains a challenge to motivate employees and teams to share this power.

About Team Members Types/Personalities in Agile Projects

We have written about how the agile coach deals with the different types of team members observing and determining the right level of support and guidance to give.

Based on a few past projects, we could identify a few team member personalities and behaviors that have a positive and negative impact on the execution of the project.

The Team Members Types

1. The I-take-that or filling-the-gap type

Reliable and willing to learn, valuable as loyal supporter of the team, hates conflicts; takes on tasks enthusiastically no one else wants. Creative, solves problems: If something has to be done, he/she does it.

2. The flexible and dynamic type

Willing to try new things and a willing listener and observer. Accepts a dynamic and changing environment.

3. The positive and negative feedback-giver

Analyzes and understands every project detail and complexity to give valuable feedback. Supports the team with difficult decisions.

4. The understanding and good-vibe type

 Doesn’t complain when other team members cause problems or rework. Gets on and does the job with a positive outlook on how to succeed.

5. The why-should-I-collaborate or the LONE-RANGER type

Give me my task and I work on it. I don’t want to speak with any one, If I need something, I won’t ask. I will make a decision alone. He/she likes working alone or only with experts.

6. The I-don’t-care-and-I am-not-responsible or DIVA type

Doesn’t care about what other team members do, but wants them to prepare everything so that he/she can do his/her job. Tries to tell everyone else what to do. Slow to see new tasks or issues, but thinks he/she does his/her job perfectly and nobody else does.

7. The I-know-everything-and-better-than-you-all type

Specialist, single-minded, can put knowledge into context, but doesn’t always want to do it.  Provides support if he/she wants to, but doesn’t recognize the achievements of others.

8. Over communicator type

To every question or discussion, explains in a lot of detail including the history of human origins. Loses people in the discussion. No one is ever sure how the answer is related to the question or the situation so stop engaging altogether.

9.  Indecisive type

Indecisive, un-inspiring and slow-moving. Gets the job done in silence once someone else makes the decisions.

10. The tell-me-what-to-do type

With lack of initiative, he/she needs a plan and that somebody tells him/her what to do and he/she will do it. Does not take personal initiative.

 

In addition to the personality and behavior experience with the subject domain is also a factor. It is possible to work with all these types in agile projects; it is a matter of coaching, facilitating, and observing as posted in our past article.

We are sure there are more TYPES and would love to hear more about them from you.  What is your experience regarding team-personalities?

Going Agile – Coach and Empower the Team

Working in an agile project as a team can be like sharing an apartment: there is one team member who usually cleans up, while another one never sees the mess, another one never shares anything and yet another one borrows everything. Some people drain your energy and it takes determination to deal with them.

A similar situation occurs to agile projects. The whole team shares a working environment. You are supposed to be generalist and do any story required to deliver. You are supposed to accept change even late in process.    

Personalities – By V.Vaca

Based on a few past projects, we could identify different team member personalities and behaviors that have a positive and negative impact on the execution of the project:

A – A team member is able, but unwilling or insecure?

B – or is unable, but willing or confident?

C – or maybe able and willing?

Dealing with the different types of team members requires the Agile Coach to observe and determine the right level of support and guidance to give. The Hershey and Blanchard Situational Leadership frameworks based on the two dimensions of support and guidance suggests the following actions are useful in developing team leadership abilities depending upon the quadrant in which the person is located.

1.The Agile Coach offers training & guidance 

2.  The Agile Coach explains & clarifies

3. The Agile Coach shares ideas & facilitates   4. The Agile Coach observes & delegates

Coach & empower the team

Adapted from: Hersey, Paul, and Kenneth H. Blanchard -Management of organizational behavior (5th Ed). Englewood Cliffs, NJ: Prentice Hall, 2008

Different types of ‘team members’ can be placed in the Hershey and Blanchard quadrant based on their behavior, willingness, and abilities to participate within the team. Depending on the quadrant, an Agile Coach could provide details on agile values, principals, or practices to the team and use agile events and games to support the team develop development.

 

 

My Visualization Tips – Keys to Creative Visualization in all Project Management Phases

In the last months, we have been writing about Visualization in projects on our blog. We have shared a few tips and our experience in making projects v i s u a l. We covered not only project data in the form of charts and diagrams, but also project relevant information such as requirements, expectations, and budgeting. We focused on using visualization to help avoiding misunderstandings, inefficient meetings and a demotivated project team.

In order to improve my visualization knowledge, I attended a workshop on this topic. I learned how to be creative and professional in team building meetings, project planning phase, or in holding a presentation.

The following visualization is the agenda for the workshop (Source: Visual Braindump): 

There are different ways to approach the different phases of a project – from a project initiation to project retrospective. For me it is important to keep it simple and yet informative.

Here are my personal learning on being or becoming visual.

1) Don’t be shy, be creative

Sometimes I don’t like to talk in front of other people or cannot explain in words what I expect on a project. Putting my ideas on paper writing and drawing my expectations during the project planning phase can help the project team to provoke a reaction and discuss the different topics. In the workshop, we did an exercise and learned that people remember what was discussed in a more effective way than the spoken words when it is associated with a visualization. We were also encouraged to make our own drawings and take our own pictures.

The comment “I cannot draw” is not applicable. The workshop also proved that everybody can draw.

The following picture is the result of drawing something based on our daily work/tasks using every letter of the alphabet:

2) Synthesize complex ideas and task by drawing them

As humans, we can transmit complex concepts using pictures. This is something robots cannot do. Those pictures can be interpreted by people with different cultures and backgrounds better than words. The capacity of synthetizing an idea, problem, task, or risk in form of an image using your own imagination, creativity and experience is endless. For sure, this will catch the attention of the whole team more than 1000s of words.

The following picture shows a roadmap for a beer brewery project:

3) Feel proud of what you do

It is not only the project manager and SCRUM master that leads the visualization process. Team members can contribute visualizations to the project to make themselves part of the decision-making process. I feel prouder of my work when I am part of the decision-making process, no matter how small or big my contribution is. In my experience, this contribution will increase the personal and professional involvement and the consequent success.

4) Be an active part of the Team – You are more than a role

Visual thinking is about communicating and expressing what I see, feel, think, and know, by drawing; like children do. Using visual thinking in every project phase – from team building to project retrospective makes the project alive. I learned that every task can be interpreted and thus visualized in a rational, emotional or practical way.

The following pictures show

  •  A ‘persona’ that shows a potential user

  • Different approaches -head (rational), heart (emotional), hand (practical) to different project aspects.

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.