How companies limit project success

It always seems impossible until it’s done – Nelson Mandela

Companies can limit project success and may not even know it. If they do, they tend to ignore it at first and move ahead, often up to the point where it really becomes broadly visible and dismaying. By then the damage has already been done and it’s hard to recover, if at all possible.

Technology-driven-change projects have a massive impact on the organization, because they touch people, processes, and technology all at once and deeply. Before you start the project, you need to take care of a number of derailing factors that can be deeply rooted in your company’s DNA and culture.

I will list a number of these factors first (not meant to be a comprehensive), select a few and address those in greater detail: 

• Establish leadership alignment and commitment on vision, scope and strategy
• Remove silo-ed behavior of departments and groups
• Assign full-time, qualified people on the key positions
• Implement governance structures within the project and outside with external stakeholders
• Focus the team on the key tasks by minimizing distractions and prioritizing the work
• Educate project staff on how to execute key tasks and what the new technologies are about
• Select qualified business partners to help you deliver and act upon their recommendations
• Adequately resource the organizational change management team
• Communicate the project scope, timeline and strategies over and over again

The factors that I have picked to explain in more detail below are not necessarily the obvious ones, but they can be very detrimental to the project outcome. 

The first factor is about silo-ed behavior of departments and large groups. Traditional, function-oriented companies struggle in today’s fast pace world with cross-functional collaboration. The majority of the leaders of these organizations are still very comfortable in their verticals and do whatever it takes to optimize the fragmented reality of the day for themselves first, and others second. When they engage in cross-functional activities and communications, they appear to work well together, but in reality they hardly do. This is a severe challenge for projects who are implementing enterprise business solutions.

It is very hard to course correct this behavior and oftentimes requires people changes to remedy. A short term effective measure is to work with performance metrics that stimulate cross-functional collaboration at the executive and mid-level of the organization. Another short term measure is more frequent involvement of the CEO or GM who can bond the team of senior leaders, foster the right behavior and make key decisions in adversarial situations.

My point of view is that traditional, function-oriented business models don’t work effectively in today’s world. Instead, organizations should strive for a horizontal design of their business operations. They should orient their structure by end-to-end business processes and lines of business. It is business process first and then function, instead of the other way around.

The second factor is about distraction and competing priorities. Most people and project teams struggle with getting things done when there are too many tasks at hand at once with similar deadlines. They have a hard time dealing with planned work that happens concurrently. At the same time, they are getting distracted by unplanned work that grows in volume towards the end of a project phase. When the pressure goes up, the team’s progress slowly comes to a grinding halt. People start to point to the timeline being to aggressive. But is it really? What do you need to do on this front before you start the project, and as you move forward?

The biggest step to make or take is to educate the team on how to organize and schedule the work. Make sure that every project and sub-team has work planners and schedulers. Make sure that highly effective communication structures are set up. Make sure that internal and external dependencies are identified and managed. Use a hierarchy of work plans and schedules, with a MPS (master project schedule) and TWS (team work schedules) that are aligned all the time.

There has been a lot of discussion the last years of waterfall versus agile project management methodologies. Without going into detail in this post, my point of view is that for technology-driven-change projects a combination of both is most effective. As example, the baseline of the project can be waterfall oriented, but when the planned work volume peaks you use SCRUM techniques to get through that particular moment. You can also decide to use agile for certain parts of the project scope, where waterfall is more effective for others. 

There is one behavioral element that is hard to deal with when you are in-flight and can be addressed at best before the start of the project. It is called procrastination. Many people have a habit of leaving the work up to the last minute. This can be devastating if they don’t understand what the work is in detail, and when at the same time unplanned work comes up.

When you staff the project team with internal and external resources, be aware of the core personality traits of the key resources on the project. Do not only focus on the expertise that the person can bring to the project, also focus on ability to deliver under pressure and tight timelines, collaboration with other individuals and teams, and verbal and non-verbal communication skills. Get the right team on the ground. From your own internal organization, and from the business partners.

The third factor is about project management capability. Companies limit project success, because the majority of the resources they assign to the project don’t have  the right level of knowledge and experience to manage a project. Let me be more clear on this. Every resource in the project has a responsibility to manage the project to some degree. For the program and project managers it obviously is a full-time responsibility, for team leads and team members it is a partial responsibility.

An example of what happens quite often is an issue that should be reported upwards to the project level, stays far too long at the team level without a decent chance of getting an effective response. When it does finally boil up, the severity and impact has gone up dramatically with less time for resolution. Another example is work planning and execution. It happens regularly that project resources get stuck with their project work, because their functional leader has other non-project work assigned to them that the project leadership is not aware of.

What you also see is that the initiative is not managed as a true project, but more as an initiative that functions as an extension of the departments involved. Let’s say there are two departments leading the initiative. That means there are two circles of influence that overlap. Ideally the overlap would be significant. Project resources operate where the circles overlap. You may call that area the project. In such a situation, project resources tend to go to the home base first to discuss anything that is related to the project. Once that happened, they may or may not discuss it within the project. This occurs because the traditional function or department is stronger than the project. What should it actually be?

There should be three circles of influence. The two circles of the departments and a third circle, being the project. The project needs its own identity with its own leadership, governance and resource structure. With the project assignment, resources move over completely to the project and only report to the project and not to the home base they originate from. At the same time, the company must have a clear strategy of how project resources at the conclusion of the project flow back to the organization. Such a strategy builds trust and gives comfort to the project resources, because they know what will happen in the long run.

An example of a behavioral issue that happens all the time with two circles and not with three, is accountability. When there is no true project (two circles that overlap), the needs of the home base can take precedence over the needs of the project. Resources tend to ignore project leadership in favor of their functional leadership, because they know that in the long run the functional leader has more impact on their future at the company. This is a situation that is not beneficial for anybody: company, department, project and resource, yet we still allow it to happen.

Before companies embark on technology-driven-change projects, they must take care of a number of factors to maximize the potential for success. I am a firm believer that projects do not fail of the technology itself. If they fail or realize less benefits than planned, it is about key decisions the senior leadership team did not make properly before the start, or not adequately executed them while in-flight.

If companies want to deliver projects and achieve the planned benefits, they must set people up for success. If they do that for each individual, they will build high-performing teams and get the anticipated results. Make sure you have got all of the factors addressed before you go. Investigate what leading practices or world-class standards are and implement them. Use the expertise from professionals in the marketplace to get you off to a right start. Build the right project platform to operate from.