Most organizations have experienced projects that did not end on time, were over budget, changed in scope over time, or at the end did not bring the expected value. Undoubtedly, all projects look simpler in a Powerpoint or Excel files produced by managers, but in reality, on a daily basis, the situation is much more complex. Projects are full of uncertainties, and failure to identify or manage those uncertainties appropriately can rapidly develop into serious problems and issues.
On the one hand, during years of working in the IT sector and being a part of many different projects in a variety of companies, I’ve seen mistakes that were constantly repeated. But, on the other hand, I’ve also noticed some positive methods that brought many projects to a successful end. So what are they?
Defined goals and business value
The most common fault which I noticed in almost every project is the lack of a clear, well-defined purposes and goals. And, even though, at the beginning of some projects efforts are made to define their visions and objectives, they are often forgotten during the decision-making process or are not disclosed or known to all members of the team that eventually executes the project.
And, failure to understand the question “why” regarding the projects may lead to a misunderstanding of the real needs of the organization and a complete waste of company’s money and the employees’ time. This problem can be easily illustrated by statistics - more than 60% of features in software products are rarely or never used.
Moreover, I believe that before we can even begin to think about budgeting, or estimating the amount of time that the project would take, it is critical to know what business value we want to have. This value will be our base and guide in the subsequent decision-making process during which we will need to decide which parts of the project and which requirements we will deliver first.
Set priorities and split the project up accordingly
When we have defined business values and goals, we are able to prioritize requirements that we want to deliver during the project. These priorities will help us to divide the project into smaller phases. Such an approach has two very important advantages.
First of all, we deliver the most important functionality first. This helps us to verify whether we have set and understood the business value correctly, and to make sure that the crucial features are delivered. This approach is connected with the Pareto Rule, which says that 20% of the things you do create 80% of the results you get.
This 80% may be enough to deliver the business value with a lower cost than we would need to pay by implementing the entire scope. In fact, when we divide the scope into smaller phases, it is also easier to correct or even change the scope of the project if we need to do that.
Second of all, if we have difficulties with delivering even the first phase of the project, for sure it won’t be any easier to produce something with a larger scope, higher complexity and bigger scale. I’ve seen a couple of long term projects that failed to deliver any working software thanks to too large of a scope and the never ending process of adding new requirements.
The example of such a project is one that I’ve seen in one of the telecommunication corporations which wanted to change its core system. After two years of exhausting attempts to replace the existing solution, the stakeholders of the company realized that the new system wouldn’t be able to provide them with the basic and the most important process of selling new subscriptions. The company lost two years and huge amounts of money, because at the beginning it chose to implement less important, less risky but easier processes and failed to deliver the most important business value.
Execution on a daily basis
Well-defined priorities based on business value assure that the team focuses their energy only on high priority work, but it does not necessarily guarantee that the work will be done efficiently.
Parkinson’s Rule suggests that the average person who is given two weeks to complete a task will instinctively adjust his effort so that it actually takes exactly two weeks.
That is why most of the agile methods such as Scrum focus on small iterations, everyday statuses and the assumption that the team commits to deliver working software at the end of every “Sprint” (Sprint is a term from Scrum: a repeatable cycle of work). Basically, to increase the probability of delivering a finished feature by the end of the cycle, at least two things are needed to be done before every cycle.
First, the tasks that will be developed during the sprint should be described in detail with the help, involvement and acceptance of the future users. The most frequent problem that I noticed during software production is the lack of having a proper decision-making process and the lack of communication with executives on daily basis. Usually, the pressure is put on the team, resulting in a situation in which it can’t wait for the engagement of stakeholders and it needs to make assumptions about how the users would like to work with a given functionality. Unfortunately, such an approach rarely has a positive impact on the project.
Second, the task should be split up into smaller issues that could be accomplished by a team member during one day. This approach helps to keep the motivation level up and makes the team’s progress more visible on a day-to-day basis. Below you can see a short video showing how it can be done for the time after work.
Each sprint should be completed by showing to the future users what the team produced during the sprint (in Scrum it is called Review). The possibility to present what we delivered significantly increases the motivation of the team during the sprint, but also minimizes the risk of producing something that does not deliver the proper business value.
The transparency and visible progress helps to build up the trust and engagement of both executives and team members, but, undeniably, also requires a lot of additional work, availability and cooperation, which may not be that easy to achieve.
Removing obstacles
The last, but not least causes of pain in almost every project are the unresolved issues, unremoved obstacles and lack of constant improvement. Unfortunately, problems have a tendency to grow, overwhelm and discourage team members over time. That is why, in every project, a review of team activities and existing obstacles (in Scrum it is called Retrospective) should be conducted cyclically. Retrospective will provide a constructive glance at the recent past and enables the team to evolve its capabilities over time.
Several weeks ago, I was participant in such a team retrospective that was conducted between five different teams 
working together on connected projects. The idea of the retrospective was simple and promising. We were divided into several groups and asked to write down answers to three questions:
- name positive actions that we should continue to do in the next phase;
- identify the problems that showed up and should be fixed in order to eliminate them from the next phase;
- list the things that were missing during last phase that we should start doing.
Every team produced several post-its with detailed answers for the questions mentioned above. Some of the issues were repeated in every team. After collecting and sticking all the cards on the board, every team member had three votes that could be casted by marking a dot on the cards that contained the problems which disturbed the team’s work the most. This part was also conducted with enthusiasm and at the end of the exercise we had a few cards on the board that were the absolute winners. Thanks to such an approach, we knew which issues should be resolved as soon as possible.
And then the troubles began… We were running out of time and hadn’t propose any action points to deal with these problems. And, even though some ideas about resolving issues surfaced, no one wanted to take responsibility for resolving them or, at least, monitoring them. The meeting ended and the problems remained untouched - as usual.
Although in our teams there are three different project managers and three different Scrum Masters (a role in Scrum which is accountable for removing the impediments), and I asked them about next steps that were planned, but the situation still hasn’t changed up and until today. I don’t know if it is a matter of overly conservative people or poor processes, but I do know that such unresolved issues are detrimental and significantly lower the productivity and motivation of teams. Ultimately, in order to change anything, specific actions and not words are what is needed.
Summary
Managers often use project plans, timelines, and budgets to reduce the risk of a project’s failure. They hope that the team will be able to plan all the actions and dates of a complex project in advance, even though the team is not able to accomplish it. In many cases, predictions written that in Excel files and Gantt diagrams are nothing but crystal-ball musing that ultimately distort the truth.
I believe that instead of wasting time by continuously updating Excels with plans in the distant future and looking for reasons why our estimations based on poor data failed, it’s better to deliver and celebrate small victories, because as Peter Marshall said:
Small Deeds Done Are Better Than Great Deeds Planned
This rule works also in other areas in our lives, so I encourage you to read our previous post about using these powerful small steps in order to achieve any goal or to start planning and setting your goals right away with the Cayenneapp.
