A development project (un)successfully started is soon discarded - 5 scenarios for your project risk analysis

1. “Scrum is only for the development team, we need to know the timeline and budget because the board insists on it!”

Usually, the guides and handbooks will tell you to choose a project management methodology, and then describe the main points in the contract. If only it were that simple. 

Most of the time, the supplier will want to implement a project based on the Scrum or Kanban framework. At the same time, the customer may have a problem accepting a contract in which we do not specify milestones or the budget. 

Sometimes we also have a general outline of the scope within the contract. This is how we end up with a hybrid… meaning a combination of an agile approach and a waterfall. I’ve been there – have you?

Let’s take a look at a specific situation: a customer from the catering industry had a very clearly defined deadline. The peak of the season was the moment when the application had to run flawlessly. 

The scope of the project was extensive and imprecise, and it was supposed to last almost a year! 

At each refinement stage, the client proposed complex ideas for the implementation of the requirements, and the development team had little decision-making power. And of course, the client expected implementation within the time frame and budget that we declared in the contract.

What we learned (the hard way) about risk analysis:

We should have committed to the final deadline, but only if the development team had an impact on the implementation method, and the Product Owner prioritized the functionalities by first handing over the most important ones for implementation and accepting that the tasks with the lowest priority may not be completed on the time. 

Unfortunately, with this client, we had to fight the clock and balance the margin and scope. It was tough on both ends. The client had to let go of some requirements, and we had to fulfill other requirements after hours (for free) at the expense of a lower margin. Have you been there? 

What you can learn from our mistake:

Choose a project management methodology and define it from the start. Most importantly, adopt a realistic framework and focus on priorities:

• If the project budget and lead time are key, do not include a full list of requirements in the contract, but focus on priorities and be ready to cut the scope. Tell the supplier what determines the deadline (important trade show, peak season), it will help to better understand the perspective and the actual goal. You can’t have everything. 
• If you want to refine and tweak your product to the smallest details, but you do not have a super-thorough list of requirements, do not specify the schedule and budget in the contract. Instead, focus on the value that could be realized by meeting the potential needs of the end user. 

2. “Go ahead and start the project, and meanwhile, we’ll process the contract.”

There are projects where the time to implement vs. deadline is so tight that one or both parties have a strong temptation to push aside formalities –  like signing a contract. Who hasn’t experienced this?

The client: a large corporation with a complicated, bureaucratic multi-stage contract signing process. Plus, the demand in their market appeared suddenly and demanded a quick jump to action. 

The project started when there was barely a framework agreement in place: one that did not specify any of the project assumptions. The mockups were ready when the contract left the legal department. 

Developers were already midway through the process when we entered the functional assumptions into the contract. The situation: release was scheduled soon, while the contract was still pending. The client was so determined to release and take off that they turned a blind eye to a lot of shortcomings. 

What could have gone wrong?

• In the absence of approval, the supplier (us)  would face considerable difficulties in claiming the payment due. It would be particularly problematic if the project lasted a long time – the supplier incurs the costs of running the business on an ongoing basis, mainly the costs of employees, without a guarantee of receiving payment from the client. If you’re doing pre-contract work, you might be doing it for free.
• In the event of numerous errors, the ordering party will have a problem enforcing corrections. (If an error is made with no contract, does anyone see the error?) If the project started quickly, there is a good chance that the requirements are scattered in many places, e.g. in e-mails, in Jira, or in Miro-type applications. So it will be difficult to determine what was in fact a mistake in operation and what is a modification. It might be even more difficult to follow the scattered pieces of communication together to get a clear picture of what’s really happening.

Lessons learned about risk:

Currently, we implement all projects only after signing the contract, even if it’s a short and tiny contract. We strongly advise you to hold your horses on development and do the same.

Sensible lawyer interlude:

Because this includes legal stuff, we consulted our company lawyer (as you should) Danuta Gogolińska-Gajda, about this particular situation, and her response was pretty clear and set in stone (as it should be when it comes to things like contracts).

Danuta says:

“While the IT teams don’t have to worry about the specifics of the contract too much (except when it directly affects their work, the drafting and negotiation are done behind the scenes. Usually, the fine points of the contract are drafted by lawyers and negotiated by managers on the client side, and sales managers (new business managers) on the IT company side.

Also, from a legal perspective, signing a contract before work begins is crucial. While the determination of what is to be contracted and how much it will cost is usually agreed ahead upon by email, other equally important issues (e.g. confidentiality clause, copyright transfer rules, or details of the parties’ liability) are not settled, and negotiating them after the project is launched can be lengthy and tiring for both parties.

What happens when the parties don’t agree on the terms of the contract? Is either party ready to walk away from the table? The supplier has already committed its resources, and the client has a project underway that can be discontinued at any time. The situation is often a stalemate for either party, which influences the project itself. That’s why we recommend that you start negotiating the contract well in advance so that you have this process behind you before you start working together.

3. “Yes, yes, carry out the project using Scrum. Oh- and what is Scrum again?”

I’ve met people who seem to underestimate the way projects are managed. Sometimes they’re people who are pretty high up on the food chain. They’ll say:

“It’s not important how, it’s important when the project gets delivered.”

And yes, I understand priorities, but if we don’t agree on one framework or some project management methodology, the communication within the team will turn out worse than it should be and cause many problems. Slowdowns, confusion, disagreements, bad timing and chaos. 

The client: financial industry. They already had a product that was used by thousands of people, but it was a bit dated and decided to create a new version using modern technologies. They also hired a new Product Owner. 

The difficulties: The new PO decided to implement the project based on Scrum because he believed that it was the best way. After all, it was crucial to create a good application, iterative, probably with many changes in scope, time was not crucial and current clients could use the existing one anyway. He was not wrong.

The actual complications arose when it turned out that he is the only person in the organization who has experience working with this framework.

What were the consequences and how did we deal with them?

At our meetings, there were recurring boomerang questions about when the schedule would be created, when particular functionalities would be delivered, and when we would complete the documentation of the entire application. 

Had they known Scrum, it would have looked more like this: 

The changes to the requirements during the sprint were notorious. Estimating in story points was an unexplainable abstraction. Stakeholders with technical competencies also tried to interfere in the way of implementing the requirements, leaving the team no decision-making.

Lesson for us (and for you!):

Part of any project’s discovery phase should be feeling out your client’s knowledge level. If you’re working with someone from outside the IT industry, chances are that you’re going to need to get on the same page as far as certain processes are concerned. 

This might involve educating your client, and maybe even some workshops. If we know that the client’s stakeholders do not have experience in working on agile projects, we explain what agile projects are all about and how they work. We discuss the roles and responsibilities of all individuals on the team.

4. “I’m the boss, but in fact, the decisions are made by HIM.”

Rapid development and growth in an organization is a great thing, but it’s also a common reason for structures not keeping up with the growth. And even if they do keep up, the management board may have a big problem with giving up control over individual parts of the company. Frankly, this is natural. In small companies, “the boss” usually has everything under control, including the small decisions about what type of coffee to order for the office. This type of intimacy is hard to change, or give up. 

It’s hard to delegate tough jobs like budget planning or HR decisions. I’m not surprised by situations where we have a Product Owner or even several stakeholders in the project, but no one is able to make decisions on an ongoing basis, because the power is still in the hands of the president, owner, CEO, or another highly placed manager. Not surprising, but potentially very problematic.

What risks have I faced in similar situations?

• We had to wait a long time for decisions, which resulted in delays
• There were also numerous misunderstandings as a result of the fact that there was no direct contact with the decision-maker. The contributor may have given his interpretation of the facts other than that of the development team
• The assumptions changed quite often because the decision-maker was not aware that even small changes can have a big impact on the application

Lessons learned:

• We now understand that we are not able to change certain processes on the part of the client, and it is not always possible to force ongoing contact between the team and the real decision-maker. However, we do try to organize an additional meeting, at least once a month. Usually, it’s like a Q&A session and allows us to verify if we are all on the same page. 
• We determine in advance which decisions in the project are completely up to “the boss”. We do not start these tasks without confirming that we have the green light from them.
• We put everything down on paper, in order to eliminate the likelihood of misunderstandings.

The “boss” conclusion:

• Research shows that a crucial factor that causes project failures are scope problems: changes in the organization’s priorities, incorrectly collected requirements, and changes in purpose. For this reason, it is crucial that the person responsible for the scope – i.e. the Product Owner – be present at most project meetings.
• If this scenario is impossible to implement, it is necessary to discover who the decision-makers are and carefully plan communication at the very beginning. For example: will it be necessary to implement technical details, will regular meetings be possible, and is there any part of the responsibility that can be transferred to the Product Owner?

5. YOLO project management

Here’s another example that we have come to know well: “We want to start the project quickly, let’s take care of the necessary formalities and start the first sprint”. This time, however, the contract was signed, and we decided to work in Scrum, the budget was relatively flexible, as was the schedule. 

So, what’s the problem? And yet, pretty soon, we started to bury ourselves in hundreds of messages on various aspects of the project organization. 

One person dropped a thread that they saw some risk. The second is that she would like to measure the time to fix errors. We started doing weekly “organizational” statuses but mainly consisted of collecting key threads from emails and slack. What did we do wrong? 

Here’s the problem: We haven’t thought about the method of reporting, or what metrics will be useful.

More risk assessment lessons for us:

We tried to introduce the “recovery plan”. We collected the client’s requirements and our own recommendations and proposed to the client the following plan:

• A dashboard for Jira was created, dedicated to the client’s needs, including bug turnaround time. 
• We have also created a dedicated report template, which includes the following metrics: a schedule with information on what moment we are currently at, a budget combustion chart with a forecast, and information about the planned availability of the team.
• Additionally, we have introduced a risk register.

General recommendations:

Referring to the PMI and PwC report, the vast majority of organizations consider checking the status versus the assumed schedule, budget, and scope as key metrics, as well as quality monitoring. In addition, customer satisfaction, risks, efficiency, and compliance with the broader strategy of the organization are measured. I am convinced that the use of these metrics will allow you to have access to the most crucial information about the status of the project.

What’s the overall project risk analysis lesson here?

There is a lot you can learn from other’s mistakes. In fact, any mistake that was previously made by any other company that was executing a similar project can be used as a learning opportunity in risk management – and there’s no excuse not to apply it to your own projects.

Mistakes and failures are free lessons handed out by the universe. The task ahead of you is to spend time on research that covers similar projects in depth. In this article, I have described multiple types of projects with many different scopes, and from many different industries. What are the particularities of your IT project and the industry that you’re working for? Are there any particular lessons that are still waiting to be learned, or have we touched a sore point?