Written by: Zsolt Czimbalmos, PMP, PBA, ACP, DASSM Senior Consultant, Managing Director
My project is in trouble! What should I do?
Everyone has heard of projects that get stuck, run into trouble, at a certain point unable to move forward despite all attempts. Valuable resources are burned by these projects, which are typically huge in size, yet in a general sense the project becomes a buzzword within the organisation.
In this post, we will explore the most common factors that cause this deadlock and how agility can be used to get a project out of it.
Most common root causes that lead to project stoppage
In our experience, the condition and characteristics described above are rarely caused by a lack of expertise in the project team. When our clients approach us with a request to help move a particular stalled project forward, we most often experience the following:
- Moving or unknown targets
The initial goal of the project is constantly changing, the team is working day by day, the project requires constant re-planning. This uncertainty is not a change in scope, but rather a change in the ultimate goal.
- Lack of focus
Project staff consider tasks as secondary to day-to-day operational or other project tasks. Too many issues running in parallel, not enough focus on the project.
- Not enough resources
Under-planning of projects is a typical problem. In many cases, resource managers do not take into account that project members are not only responsible for the technical tasks of the project, but also have to take part in meetings and administrative tasks. Let's not forget that, for example, a developer's day rarely means 7-8 hours of development, it is much more viable to calculate 4-5 hours a day.
- Lack of leadership support, motivation - we don't believe in success
Unfortunately, in our experience, in many cases the contracting authorities only play a formal role in projects, without any real added value. Potential escalation processes and approvals are slowed down by slow or delayed decisions, and this attitude is also transmitted to team members.
- Not the right people in the team
The structure and designation of the project team is not always self-evident. This multi-factorial decision should be made through a well-grounded and well thought-out process. In addition to professional knowledge and competences, the skills, willingness to cooperate and motivation of the team members can also play an important role.
- Poorly chosen methodological directions
We often say that we are not for the methodology, the methodology is for us. Each project may require a different approach based on its characteristics, and a wrongly chosen methodology can even cause a project to stall.
- Immediately "we want to build a spaceship" - excessive expectations
It is a common problem to set excessive expectations for the project, immediately striving to deliver the most complete, fully functional result possible. This not only complicates implementation but also delays value delivery.
- The focus is only on the tasks
For a group or team to function effectively, it is not enough to focus on work and tasks. The dynamics within the team, and the emphasis on and development of the team's operational framework are also necessary for a team to function and deliver well.
Agility as a possible solution?
It is important to emphasize that the following approach we use in such situations is not about "converting" the project to an agile methodology, but rather about how to help troubled projects by using elements of the agile approach and toolkit. Starting from the above roots, if we can get the team to deliver a narrowed scope, scope with focused work, with close involvement of the client, in a shorter timeframe if possible, we have a good chance of moving the project out of its stuck state.
We'll leave aside the now familiar checklist (e.g. clarify expectations, rethink the schedule, assess risks, etc.) and present the steps we use to get you thinking:
1. Rapid analysis
To get started, it is necessary to understand the problems and the cause of the stalemate. Our experience has shown that this can be done quickly and effectively through a few hours workshop with key players. During the workshop, the objectives can be clarified, the problems encountered, the competencies and skills of the team and the target user expectations can be identified.
2. Roadmap design
Either using or ignoring the initial project plan, a roadmap is developed with key stakeholders, not to create a roadmap covering all tasks, but rather a roadmap focused on the delivery of the first major deliverable, with the most important tasks. It is critical that this deliverable is a tangible deliverable with narrow characteristics that provides some level of response to user expectations. In the longer term, of course, this deliverable can be further developed and complemented, but such a "quick win" can give the project new momentum, increase motivation and, perhaps more importantly, hope for the project's completion, thus increasing the commitment of key stakeholders and the client.
3. Securing capacity, aligning the roadmap
Based on the preliminary roadmap, we will assess what capacities the organisation can provide for transport. This is a key issue, unrealistic expectations (e.g. 2 people with a 1 day per week allocation will not be able to deliver fast results) will be flagged and we will try to negotiate conditions and team numbers that are realistic to meet expectations.
If this is achieved, we will explore with the designated team members what competences will be needed for the delivery. The assessment of competencies is not done with resource managers or technical managers, but with the team members, as they will be the ones who will have to implement the technical tasks and who will know best what technological or other skills will be needed. If a shortcoming is identified, it is immediately reported to the client and a proposal is made to address it. At the same time, the roadmap developed is reviewed with the team and, if necessary, modified in consultation with key stakeholders, avoiding impossible missions.
4. Working method development, team building
For the team to work effectively, there needs to be a way of working that is known and accepted by all. Depending on the project, this can be an agile or a traditional methodological approach, but whichever you choose, we always use a task list (backlog in agile terms). This makes tasks transparent and easier to track.
In many cases, the development of the working method starts with a "mini-training", where good practices are presented and on this basis the team members agree on the schedule to be followed. We try to hold presentations for key players as often as possible and, depending on capacity, we also hold stand-ups several times a week. Delivery is organised in iterations where possible and we try to prioritise tasks strongly. The joint development of a working method and joint workshops are also great opportunities to get to know the motivation of team members and strengthen team unity.
5. Quick results, small victories
As we wrote earlier, there are no miracles. A huge "giga project" cannot be delivered in a few weeks, but it is possible to achieve "small victories" quickly, even in a few weeks, i.e. to produce a result product that is of value to the users and/or the client. While this does not cover the full list of requirements, it is a major step forward.
We place a strong emphasis on communicating the results of the project properly, and if this has not been done so far, we will try to show as many key stakeholders as possible that, with the right focus and commitment, the project can be successfully completed. To ensure successful delivery, we facilitate and support the day-to-day processes with frequent coaching support on demand, either in the role of a project manager in the classical sense or as a Scrum Master/Agile Coach, as known in agile, and/or even as a Product Owner .
Two things are important to stress about the above process. The first is that in order to really move the project forward, the working method needs to be developed in 2 weeks so that those involved do not have the experience of starting another slow, cumbersome exercise. The second is that the development of the working method and the support for professional tasks should be specific to each team and project, as this is the way to make the often generic tasks described in the books work as a real, working system.
Prerequisites that we can help you with by providing on the client side
As the above shows, results can only be achieved if the necessary conditions are in place. We most often ask the customer to do the following in such a situation:
- only start projects that are really important for the organisation, what is not important will never be implemented or will "die" in the process
- Active involvement of the client. This can take the form of supporting the communication of the project and its results, reinforcing commitment through participation in presentations, or even regular feedback.
- Ensuring adequate capacity and team availability. We have written about this before, and we can only ensure results with an adequate team and at least fixed project days.
Is your project stuck? Need help? Request a free consultation, contact us!
Designabc