The Project Manager, The Business Analyst And The Business Case

Every organization has a unique culture and I have found that often extends to how the business case artifact is created, its content and how the business case is ultimately used. When someone enters the world of project management, the business case is often described to them right away. In my case, it was introduced during a certification course at Bellevue College in Washington state. When they described the concept, they were close to the way Wikipedia describes it below ...

"A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need."

As in many other places, you will often find a divergence between how the project manager will leverage a business case for their deliverables and how a business analysts leverages it. I'm not trying to be overly critical of the project manager, simply sharing the experiences I've had. 

To many project managers, the business case is nothing more that something that has to be checked off a to do list that leads to later funding and resource allocation. The Wikipedia snippet looks to support the project manager position but doesn't include the real world flavor. To many project managers, the business case documentation doesn't need to be that good. It is rarely a deciding factor in the competition a project manager faces in getting funding and resources. Make no mistake, in many cases a project manager is in competition with other projects. If a great business case document doesn't give them a competitive advantage, they will tend to focus their efforts to the "good enough" business case. 

To the professional business analyst, the business requirements are at the top of a requirements breakdown structure and that structure needs to support strong traceability all the way down to the task level. Depending on how serious the business analyst takes traceability, high value features cannot be introduced into the product unless they can be traced all the way back to a business requirement. 

It is true that business requirements can be traced to documentation other than the business case. In fact, many times I've crafted a large RTM that didn't reference the business case at all. In one case, all the business requirement in the RTM were traced to the organizations annual report, which had these beautiful sections filled with vision statements and annual goals. 

Still, the project business case documentation and the business analyst business requirements documentation should be complimentary. In particular, if your organization does audits. I grant you that audit are rare and it is even more rare they would go down to this level. However, you don't want to be the target of an audit team if a project goes south in a big way.

©2015 Dwayne Wright