PMO Making the Business Case for the Project Published on 02 April 2012 - Revised on Rarely does a project become a project without some financial decision first being made. And that financial decision is based on the business need, the return on investment (ROI), the estimated cost of the project, the available skill set to run the project, etc. etc. etc. The list can go on and on. But one essential piece of gaining the approval of any decent sized project is the business case. Making a case for the project as a viable means to solve a business need or fix a problem that needs fixing or add functionality that needs added. Someone, somewhere…usually starting with the project sponsor…must make a business case for the project. It can be a formally documented business case, it may be somewhat informally documented if it’s a smaller project or a more informal organization or it may even be a verbal discussion – but the powers that be need to hear about the project concept and be convinced that it deserves to have money thrown at it. As projects are costly exercises, it is imperative that senior executives within the organization approve spending money on the project prior to undertaking the initiative. The way in which they are made aware of the project and commit themselves to this project is through the business case. Without a formal business case, the project is likely to be cancelled within a short period of time and will have resulted in a lot of wasted effort. The business case document therefore defines and assesses the proposed project. The business analyst develops the business case with help from identified groups, departments, and subject matter experts, and continues to update the business case in parallel while development takes place. The business analyst and project manager, together with executive involvement, should review and refine the business case into a workable document. Potential Components of the Business Case Risk management Project requirements Project definition Functional diagrams System functions Operational concept Customer responsibilities Project or end solution characteristics Functional interface definitions Projected cash flow and/or ROI Legal constraints Specifications and standards Methodologies required Preparation for delivery Maintenance and support Rate this article: No rating Print Brad Egeland Brad Egeland is a Business Solution Designer and an Information Technology / Project Management consultant and author with over 25 years of software development, management and project management experience. He has successfully led project initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Nonprofit, High-Tech, Engineering and general IT. Full biography Full biography Brad Egeland is a Business Solution Designer and an Information Technology / Project Management consultant and author with over 25 years of software development, management and project management experience. He has successfully led project initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Nonprofit, High-Tech, Engineering and general IT. In addition to his accomplishments in IT development, resource and project management, he has also authored more than 6,000 expert advice and strategy articles and more than a dozen eBooks and videos on project management, business strategy, and information technology and best practices for his own website and for clients all around the world. Brad is highly regarded as one of the most prolific go-to authors on project management. x Contact author Google Plus Twitter Linked In
Quigley & Lauck's Expert Column Mastering Quality: A Deep Dive into Quality Tools and Total... By Jon M. Quigley & Steve Lauck
Quigley & Lauck's Expert Column The Essential Guide to Project Roadmaps By Jon M. Quigley & Steve Lauck