Do your projects fail?
Don't change the methodology or people. Change the system!
Michał Rączka, MBA, Scrum PSM&PSPO, AgilePM, CISA, PMI-ACP, PMP
IT Strategy and Project Management Vice Director at mBank S.A.
When projects fail in a company, management tries to understand what went wrong. Often, first impressions are that we don't have enough skilled people or our methodology is not well implemented. When we ask a consulting company, in most cases, they conduct ASIS analysis then sell a new methodology implementation or training. Nothing or little will change. The challenge is in the system of work. System of work consists of such things as structure, hierarchy, goals, multitasking, team dysfunctions, and planning horizons. All of this and more influence our projects every day. Although systems of work are around us, it is not visible. That is the challenge. This paper describes the system of work and ten areas that can be improved, provided as lessons learned.
- Understand what parts/layers create every organization and how this influences the realization of strategy through projects.
- Understand what the system is and how it influences project management in an organization.
- Learn what parts of the system can negatively influence our projects and the root causes of why our projects could be failing. These can be obvious things, but not visible at first sight.
- Gain an awareness of the system parts and how you can fix these parts.
When we look at the Standish Group reports, we can see that nothing has changed. For many years, statistics about projects were similar. More than 70% of projects either fail or experience serious difficulties.
When projects are failing, the company management will want to do something about it. Many times, the very first discussion is about the methodology used. As a panacea for failing projects, we usually change/modify a methodology, provide training, and then hope for better results. This is currently a very common issue, as many businesses look to switch to “agile methodologies”.1
Imagine a scenario where an organization has failing projects that are impacting business results. The management wants to act and wants to see results very fast.
It's like the Fatboy Slim Song: “Right here, Right now”!
They have employed a consulting company to do ASIS, TOBE, and GAP analysis. They deliver proposals on what should be changed within the methodology. Then, training, certifications, and implementation begin. The result? Nothing has changed. Or maybe there are some small changes, but in reality, the projects are still failing.
The reason? It is a very comfortable action from the management point of view because changing methodology is easy; it doesn't necessarily require the people to change.
So, what's next? If it isn't the methodology, then what can be done? Maybe we have the wrong people? Let's fire them and hire new ones. This is just a management excuse and only invites more risk into our workplace. Management envisions that this will deliver a better future, but this still doesn't solve the problem.
People are adaptable and talented, but an environment that facilitates a creative atmosphere is vital to get maximum productivity from teams. If you get the environment right, then creativity will organically flourish like a living organism.
As it is stated in Lean Management: Do not change the people – change the system. People are good and they need to have a healthy organization system around them in order for them to perform to high standards. If the organizational system is good, then the people will adapt and perform well. To enable us to create this environment, we need to understand how System Thinking works.
To enable us to take this concept forward, we need to define what we mean by system and where it is in an organization, who is responsible for the system, and who creates it. To enable this, we can map every organization to a five-layer pyramid as shown in Exhibit 1:
Now we can compare the Old Project Management approach and the New Project Management approach in an organization as shown in Exhibits 2 and 3:
It is easy to change the practices or methodologies (mechanics), but this part of our work accounts for only 20% of our success. Of course it is important, but organizational culture (people, values, and system) is more important.
Organizational Culture Over Organizational Mechanics
As project managers and leaders, we are responsible for values and the system of work. We should focus on this in order to create a healthy organization ready for successful projects. We are responsible for the system!
There are many white papers and conferences where a lot of people are talking about how we should change the ways of working, we should work on better communication, or we should be focused on leadership in order to better manage organizational strategy and projects. We all agree with it, but when we return to the office, we have questions: where to start, what to do, and what to do in order to move in a good direction?
This white paper covers 10 actionable “lessons learned and to do's” based on observations and experience in a few organizations where changes in a system gave about a 400% productivity increase and skyrocketed the happiness index.
1. Structure, Hierarchy and Communication Barriers
We used to say that the most important competence of a project manager is skillful communication. All project managers know the communication lines equation: the more team members, the more communication lines. Traditional structures (silos), by their nature, create communication barriers on the system level. As each silo is competence-based, in order to deliver a project, we need elements from across the organization and a superhero project manager to glue all the communication lines together.
This is very hard work, and in most cases impossible, to communicate every one. So many times, I saw in the lessons learned log that “next time we need to improve our communication,” in order to have better project results.
This approach is wrong at a system level, as it doesn't matter how much time the project manager spends on communicating with others.
Team members can communicate amongst themselves without a project manager. They need to have a system of work, which allows it to happen in an easy way. If projects are important to us, then we need to focus on them. We need to create co-located teams where all the competencies needed to deliver projects are in one place. This is worth doing when projects last longer than one to two months. In order to do this, the organization needs to be flexible and adaptable.
Does your organization promise flexibility and adaptability to prospective customers in its sales approach?
Another aspect here is our approach to hierarchy and management. In order to scale our organization, we need to divide into smaller groups and manage them. The easiest way was to divide them based on competencies and put a manager on top of it. When we talk about communication lines, it is even worse where communication must go through a manager, as this causes another communication barrier.
Imagine how good a project manager must be to overcome all the barriers created by the sum of results of a silo-based structure and hierarchical communication.
We need to create interdisciplinary customer teams where communication between team members is natural and goals are focused on customer/project results.
2. Team Dysfunctions 
Do you have a team or a group of people? Do the Team Self-Assessment to see how they measure themselves on the following dysfunctions:
- Absence of Trust
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability
- Inattention to Results
If any of them exist in a team, then you will not be able to deliver projects. Results of measurement are also very helpful for you as a project manager. This gives you an opportunity to work with a team in order to excel as a great team
3. People Competencies vs. Structure (Individual vs. Standardized)
Silo-based organizations care about standardized competencies because it is easier to manage and replace. People in such organizations are experts in their domain, but rarely are able to be focused on customer goals. They are measured based on expertise. What you measure is what you get. When you build a project team, first you have to create a list of competencies you need, and then fill it with people who have those skills. You can build cohesive teams by combining complementary competencies. You need to focus on an individual's competencies and develop them, as this will grow the team and deliver great results. Projects are not production lines—standardization doesn't work.
4. Sponsor/Customer Engagement
Many teams complain that their customer is not engaged. The customer was visible at the beginning when requirements where gathered and shows up at the end when the project results appear. Shall we say the customer doesn't care? It is not true. When your customer appears to be disengaged with your project, reassess what you communicate to them. Do you communicate with status reports or product realization? Can you show a product in the middle of projects, or just some phases with technical/engineering layers ready?
In most cases, customers don't understand how layers work, so they avoid giving you feedback and engaging. When you show a product, use the customer's language and they will engage. Customers care about what they pay for; they only need to understand progress. You don't have to communicate a lot to a customer. Show them results that have value and engagement will follow.
Also, look at your customer's attitude. Are they bored? This is also feedback for you. Maybe you are doing something that is not interesting. Talk it through. Does your customer know the team members? If not, then this may also reduce engagement.
Another case is about internal sponsors’ engagement. Here, there is one rule: “If the sponsor doesn't care, why should you?” My lessons learned here is, when the sponsor doesn't care, then you can simply put the project or reporting on hold. If no one notices, then you will have an answer. Be brave and check!
5. Project Manager/Leader and Competencies (Renaissance Man?)
For many years, we used to say that a project manager should be kind of a Renaissance man and that all project management competencies should be industry agnostic. That probably was true 20 years ago when industries ran similar management methods. Now, that all has changed.
Do you want to be a task coordinator or a project leader? In order to be a true leader, we need to also have technical competencies. This is especially true in new technology industries. Project managers, in order to be great leaders, need to have technical and digital competencies. Understanding the business and technical aspects of the industry is very important. The team expects more and more from leaders; the same as we expect more from teams. Competence leadership is a system change. There are no longer generic project managers; there are no longer Renaissance men and women. The talent triangle - the technical, leadership, and strategic and business management expertise – is shown in Exhibit 4.
6. Goals (Individual, Team, Hierarchy)
One of the most important “game changers” in a healthy organization is how you manage your performance system. Do you want to have a team or a group of people? It is very important how we manage goals and performance appraisals in a company.
What you measure is what you get.
A team is what you have when people have the same purpose and goals. This is obvious to understand, but rare in many organizations. In most organizations, people have individual goals. The manager gives an individual a set of goals and then, after some period, there is a performance appraisal. How, then, can cross-functional projects succeed when we have a group of people with individual goals from managers? Even if the project manager builds a team with a workshop defining project goals, this is not a system change and by performance appraisal time, people will think about their individual goals.
Go and see; check with your team members about what their goals are. In the technology industry, there are ongoing discussions between business and IT. Technical people do not understand business people and vice versa. It is not that we use different language, but that we have different goals.
Another very important aspect of goals is how they are managed in a hierarchy. Companies want to realize strategy through cascading goals from the top. So how does it work for leaders? Leaders have a difficult challenge to connect these different worlds. We are leaders of a team and members of another team (e.g., the management team) and we tend to put our own team goals to the fore. It is natural, but also very dangerous for companies. That is why moving from strategy to execution is so difficult. Strategy realization plans should be transparent and visible to everyone. We should always ask a question to ourselves about how our own goals and our team goals correspond to the strategy of the organization.
It is well known that multitasking is bad for us. The more contexts switching, the more time we lose. Our productivity goes down. It is even worse when different tasks are coming from different people in the organization. Although we know about it, most of us work in such an environment. Why does this happen? It is the utilization myth. Companies want to utilize employees as much as possible. Due to bureaucracy, we have working stopovers. In order to fill our idle time, we start on another project. We want to achieve 100% utilization, which is against productivity. If you work on more than two projects, your productivity decreases dramatically. Companies using system thinking need to dedicate teams toward value creation. Ask your team members how many projects they are working on. Check the percentage allocation and the results; then act on them.
8. Risk Management
Risk is a negative value. The bigger the risk, the bigger the value. When there is a feature in our product that provides an opportunity to gain big value, then we prioritize this feature. We should do the same with risk. The bigger the value of risk, the higher it should be on the priority list. We should avoid spending time on traditional risk analysis. If the risk represents big value, we should test it at the beginning. We should create such an environment where we can simulate risk. If it will monetize, then we should adjust our thinking. The higher the value of risk, the more execution focus should be applied. Test the risk and assess how big the impact can be.
9. Planning (Long Term vs. Short Term)
The more you plan, the better results you can achieve. Is it true? Not anymore.
We should be focusing on planning as a discipline and being responsive to the changes. Forcing detailed planning in the beginning of the project is dangerous. First, our adaptability level goes down dramatically: we get used to our plans and, even in changing circumstances, we follow what was planned. We are not even open to other opportunities. Second, we want to secure our plans as proof of our professionalism. We want to secure our ego. We cannot be wrong, as our plans are great. Following fixed plans reduces our flexibility.
Also, with long timelines, “the student effect’ appears. We postpone our work to be done as late as possible. As we get close to deadline, we have a crisis situation. This causes another crisis on other projects.
10. Adaptability and Resilience vs. Security
We want to be able to adapt to new situations and changes in our environment. We want to be resilient. There is a huge difference between what we want and what we do or what we are allowed to do. Every adaptation is also a change. Every change is unsecure because it introduces something new. People in organizations want to be sure that every change will be perfect and do not allow for any mistakes. A system of work should create an environment that is ready to test a change in a secure way. For example, do not assume the change will be perfect. Assume you are probably wrong and you will want to test it. This introduces trust.
In an organization's mission statement, it is easy to write, “we are resilient,” but then the system of work drives the opposite actions.
All of them appear to be obvious and easy to understand, but they are not visible in most companies. This is because we get used to them and being close to the details, we see them as our status quo. This makes it very difficult to realize that it can be different.
Observe the above lessons learned in your project and act from the very first day back at work. In a few steps, you will be able to check what does not work and can make a plan to improve the situation on the system level. Be brave!
“Beg for forgiveness; don't ask for permission” - Tim Ferriss
Change the system, not people. People are good and want to be good. We need to have a good system around them to enable them to be good. Change the system and the people will change themselves.
Let's change our organization:
“…goal is to be happy while learning new things and creating value in a network with other people…” Jurgen Appelo
Lencioni, P. (2002). The five dysfunctions of a team. San Francisco, CA: Jossey-Bass. Retrieved July 10, 2015, from http://www.tablegroup.com/books/dysfunctions
Wikipedia. (n.d.). Renaissance man. In Wikipedia, the free encyclopedia. Retrieved July 10, 2015, from https://en.wikipedia.org/wiki/Renaissance_Man
1 Personally, I don't believe in agile methodology, this is more of an approach and people mindset.
© 2015, Michał Rączka
Originally published as a part of the 2015 PMI Global Congress Proceedings – Orlando, Florida, USA