When was the last time your project finished within the timeline and cost? Did the Team do much overtime? Did it meet the entire scope of the project? In this article we’re going to look at the illusion of security we have on projects with a fixed scope and how to get out of this trap.
The management of software projects, like the cascade model of software engineering, are greatly influenced by traditional engineering. They have a long analysis period in which the “whole” project scope is drawn up, analyzed and detailed. Based on this, the project timeline is created, resources estimated, the cost is budgeted, taken to the client and after a bit of back and forth, finally approved.
The great advantage of this type of concentration is that it is comfortable for both the client and service provider. The scope is known, as are the timeline and cost. “We know” who and what activities will be carried out on the Tuesday of the second week ten weeks hence.
[fusion_imageframe image_id=”2664″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”center” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://knowledge21.com/wp-content/uploads/2018/06/The-Project-Management-Triangle.png[/fusion_imageframe][fusion_text]
The Project Management Triangle (Iron Triangle) – Cost, Scope, Schedule
And what’s wrong with that?
Let’s begin with the problem of the metaphor of construction in civil engineering being used for building software. In engineering, if you want to build a road going from Point A to Point B, you can make a preparatory study to find out the distance between the points, soil analysis, the types of material etc. In the end, you’ll be able to estimate the cost and timeline based on these variables. Furthermore, the way roads are built is relatively stable, in other words, the context of the construction doesn’t change frequently and the construction process can also easily be replicated.
But in software development projects, the endpoint is unknown. You can go from Point A, and find out it makes no sense going to Point B, you go to Point C, and then deviate to Point D. It’s possible you’ll have to climb mountains, cross oceans and during the first 100 meters find out it makes no sense to build the rest of the route. The “road” of software is ill-defined and its product will probably never be finished. It can always be improved, evolve and adapt to the mutating necessities of the business.
Ask yourself: if you had to start a software project today, would you know exactly which technologies will be used? People involved in the project? Which functionalities will bring the company a return? The reaction by users upon using the product? Would you know exactly what you’ll be doing a year into this work? If not, how can one expect this of a project?
Assuming very high risks
Since the beginning and end of software construction are uncertain, do you know the risk you’re taking on in fixing the scope of a project during the early phases?
When Boehm wrote about the Cone of Uncertainty Applied to Software Projects in 1981, he thought the error in the estimate at the beginning of a project’s scope might be up to 8x. This error decreases as we find out more about the problem and solution of what we’re doing.
[/fusion_text][fusion_imageframe image_id=”2665″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”center” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://knowledge21.com/wp-content/uploads/2018/06/Cone-da-Incerteza.png[/fusion_imageframe][fusion_text]
Cone of Uncertainty (Boehm, 1981)
In practical terms, let’s say you’re responsible for a software project. Your client briefs you about his wishes and you competently carry out excellent analysis, planning and size measurement of the project. Based on this measurement, you estimate the project’s total cost to be R$1 million with a timeline of a year. In your vision, everything is so concrete that you commit to a specific date. On 25th June next year, the client will take delivery of his project.
Unfortunately, regardless of the arduous planning, measurement and prevision work you carried out, the Cone of Uncertainty will act on your project and scream that you fixed your project’s scope far too early and may now cost up to R$4 million over four years.
The client doesn’t know what they want
“But it’s not my fault, the problem is, the client doesn’t know what they want and keeps changing the project’s scope the whole time.”
Free yourself of invalid principles. The clients don’t know what they want and that’s a FACT! We work in the economy of knowledge and every time you create something and give it to your clients/users there’ll be a reaction to your product. There will be an impact on the business and its metrics, new ideas emerge, people’s behavior changes in relation to the problem the software is solving, and the scope changes.
Furthermore, who said the client is the best person to describe the software to you? He’s the person with the problem and expects you to provide the solution to this problem.
When you go to the doctor, do you go along with the treatment, or tell him the problem and expect him or her to decide on the treatment?
And contracts with software “factories”
But here we have a problem. Today I contract software “factories” with fixed scopes. There are many ways of contracting software projects with the necessity of fixing the scope. This video by Marcos Garrido shows one of the models for those going outside the fixed scope.
[/fusion_text][fusion_youtube id=”cK2uS4c91Tc” alignment=”center” width=”640″ height=”480″ autoplay=”false” api_params=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” /][fusion_text]
Keep following our blog because soon we’ll be publishing some specific articles about contracting software projects.
Important points for getting out of this tangle?
Be agile, but not just anyhow and end up using traditional paradigms masquerading as agile. Be #TrueAgile:
- use short feedback cycles (planning, construction, and delivery);
- prioritize and construct what’s most important first;
- validate what you’re doing the whole time, measure the results of what’s being delivered;
- measure your product and know what is giving a return and what is not, fundamental for defining which functionalities need investing in.
Most importantly, never forget: “Respond to change over following a plan” (Agile Manifesto, 2001)
Would you like to learn more? Check out the links below:
