Our discussion this week focuses on the project business case and how it has changed its focus in Agile projects.
A business case is a special piece of documentation which justifies the project undertaking. The business case should describe the reasons for the project based on estimated costs, risks and expected benefits. It is created in the pre-project process so that it provides input to the project chartering process in the project initiation process.
The business case is usually refined with more details at the planning stage. Once the project charter has been signed –off by the project sponsor, the business case should then be maintained throughout the project life cycle.
One interesting aspect to note is that the business case is one of the few project documents which are not closed at end project/phase stage.
The business case is not closed for obvious reasons meaning that stakeholders will need to account for post project benefits. This is why a business case in most instances will have to accompany another document called benefit management plan or benefit management approach. The benefit management plan documents and defines the necessary activities to maximize and to sustain the benefits provided by the project.
When building a business case it is important to clearly understand and appreciate the following terminologies: What are project outputs? Are there differences in project outputs, outcomes, benefits and value? Let’s try and define these terms in simple terms.
A project output is a product or service delivered by the project team in other words it is a deliverable. An outcome is a measurable effect enabled by project outputs. An outcome can either be negative or positive. A benefit is a positive measurable outcome whereas a dis-benefit is permanent negative realized outcome as far as project objectives are concerned.
I have seen many people get tempted to classify dis-benefits as risks. No they are not, because project risks have a likelihood or probability of materializing whereas dis-benefits are known with 100% certainty that they will materialize.
Last but not least we define value as net benefits as perceived by project key stakeholders meaning that value is realised without considering costs incurred in realizing project benefits.
The next question is to consider what goes in the business case. PRINCE2® business case recommends the following sections for a typical classical business case: Executive summary; Reasons; Business options; Benefits; Dis-benefits, Timescale, Invest appraisal, Major risks.
In Agile project management it is important that we maintain some form of project justification and this may happen in either release, product or spring backlog. In a mature agile environment a business case would be created in some form.
As part of the vision and product roadmap there would be sufficient information to ensure that the work is appropriately justified and that it is strategically aligned to business objectives. This would need to take place before release planning takes place.
In some agile environments there may not be as much emphasis given to the concept of a formal business case, possibly for the following reasons: Teams talk in terms of the delivery of ‘value’ instead. The most common agile ways of working focus more on the value of delivering individual features rather than assessing the totality of the features as a whole in advance. Work is prioritized (in a product backlog) by a product owner in consultation with the team , in an ongoing manner, based on value and maximizing that value. In effect this plays the role of a business case and is authorized by the product owner.
The fact that customer representative(s) and customer subject matter expert are part of the agile team makes it easier to assign value to user stories in spring backlogs. Customer is also able to trade-in features perceived to have more value than others with less values in the backlog.
One thing that is more important than building the product right is to build the right product. The changes, adjustments and value assignment to epics and user stories must be consistent with project high level plan. Agile project manager will do well to maintain a Minimum Viable Product (MVP) in the business case. The MVP is presented in terms of worst case, expected case and best case. All the 3 cases mentioned must be viable and justifiable from the business perspective. This allows the team to treat an MVP as learning point or lean start-up kind of strategy.
In conclusion, from our discussion, we have seen that all projects either traditional waterfall or agile need some form of business case to justify the project undertaking. Business case must be developed and maintained by the project manager or delegated to business analyst. The business case is also used for impact analysis when issues materialize in the project to support decision making. The project sponsor is accountable to ensure that the business case is responsive and strong enough to enable project success.
Though many agile environments may not support the concept of a business case, it provides an essential element to ensure that the project has been started correctly.
Having a business case is one thing, but writing a good business case is another. In agile the business case needs to be flexible and written on the assumption that what is being delivered will change in order to maximize the expected benefits of the project.
This article was written by Dr Laban Mwansa, MSP®, PMP®, PRINCE2® Practitioner, Agile®, Laban is a consultant and trainer in project management and specifically trainer/coach in PMP®, PRINCE2® Practitioner, and PRINCE2 Agile® in Zambia, South Africa and Europe for many years. He was in the executive committee of ICTAZ as technical chair. He is also the managing partner of Betaways Innovation Systems and can be reached at: Laban.Mwansa@betaways-innovations.com, +260975280392 or WhatsApp +27817029669. He is also a professional member of PMSA and PMI-USA.