I am doing some research on the topic "How have you reduced uncertainty on projects?"
I welcome your feedback based on your experience.
The Challenge
Despite the advances, delivering software projects still, continue to be problematic and unsatisfactory. The root cause of the problems I believe is "uncertainty". The solution, therefore, is to find ways to reduce uncertainty.
I would like your thoughts on these possible ways to reduce uncertainty.
1. During the project
In this option, the uncertainty is reduced during coding.
2. At the beginning of the project
In this option, much of the uncertainty is reduced at the start of the project before most of the coding starts.
3. Before the project
In this option, much of the uncertainty is reduced even before the project begins.
Your feedback
I am looking for your feedback on:
Which type of projects are best suited for approach 1, 2, 3?
What techniques have you used to reduce uncertainty (e.g. wireframes, prototypes, models, etc?)
Thanks all for your help on this. Saving Changes...
Deepa KalangiManager, Program Management, Author, Trainer| CVS HealthCharlotte, NC, United States
You are always doing risk management, which is reducing uncertainty. The sooner you start identifying and managing your risks, the more successful the project is overall. So, in your points, 1, 2, 3 you are starting at 1 and continuing to do so after 3 or even start before 1. The best way to manage a project is to start doing risk management from even the pre-initiation phase. Saving Changes...
I agree with Deepa. Identify y our risks, make a response plan and implement. This does not end here. Keep on looking for unidentified/further risks throughout the life cycle of the project. Saving Changes...
Eric SimmsSenior Program ManagerBaltimore, Maryland, United States
In my experience software projects (those managed using the Waterfall methodology) usually experience problems due to poorly understood and developed requirements, and/or changing requirements. These are the source of the uncertainty in most projects. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
By managing risk you are not reducing uncertainty by default. Uncertainty brings risk, not the other way around. The only way to reduce uncertainty is by understanding. Uncertainty is the result of not knowing what will/could or should happen. This obviously also then increases your risk exposure. So by understanding your risk, challenges, and issues, you will reduce uncertainty. I believe this is the same whether it is during planning, execution or closure. Obviously, as with risk, we can never totally eliminate uncertainty but by understanding, we can reduce it significantly. Understanding can be achieved by doing many different things and would depend on your situation.
If you are executing a project in a foreign country that requires you to import equipment then you might have a risk that relates to getting it through customs. This risk exposure could be very high if you do not understand the customs laws of the country, so your high level of uncertainty did not introduce the risk, it elevates it. You can manage the risk all you want but until you take the time to understand how the customs laws might impact your import you cannot reduce your risk. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
To understand how uncertainty works along project phases take a look to Barry Bohem´s Cone of Uncertainty, original created for software field but taken by other disciplines as a point of reference. On the other side, today there is a great amount of information outside there then you can reduce the uncertainty from the very beginning. Which impact much more in estimations is the time available to do it not the existing information. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
From a different perspective, uncertainty can be reduced by ensuring the solution is properly vetted [Architecture, Compliance, ...] and all work directly relates to solving the original problem - this will inherently reduce change requests as the customers get wide-eyed with the solution - this is the wish list. If delivery can be incremental to also ensure the solution is aligned with the business goals reducing uncertainty around value realization. Saving Changes...
You are asking how to manage uncertainty on projects related to software development.
Agile methodology, e.g. Scrum fits well, techniques like prototyping helps to clarify the uncertainty by managing customer expectations, they can test while the product is being constructed. Although software development is in most cases one of the many pieces. Uncertainty may come from other "sides", external or internal to the organizations, such as marketing, sales, distribution, juridical, etc.
In summary, agile techniques helps to reduce uncertainty of software development because it helps managing customer expectations since the beginning of the projects by showing them the progress through "fast" prototyping. Saving Changes...
While traditional project risk management activities and assumptions analysis help to identify uncertainties, good delivery practices such as prioritizing work items by risk & value and use of techniques such as architectural spikes early in a project's life can help to materially reduce the impact of uncertainty on a project.
Very insightful comments - thank you all. Anton - thank you for defining reducing uncertainty as "increasing knowing / understanding" - and that not knowing creates risk.
Here is more info on what I am trying to research:
At what point do most agile teams begin to know / understand the solution ? (by solution I don’t mean just the software, but all the people, process and technology changes needed in a larger project).
Does agile mean = to know / understand during the project?
Or
Does agile encourage teams to know / understand before the project / before execution? If so how is that done in agile ? Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Agile is a philosophy or approach to work, Ashok. It does not correlate to project knowledge.
A software developer needs to know and understand their piece of work only, whether agile or waterfall approaches are used.
If anything agile would favour working over knowing. Saving Changes...
