Skip to main content

Maximizing Project Value: Developing a Project Business Case

In my first Project Times article (January, 2007), I discussed a new paradigm shift for achieving project success. In summary, this paradigm shift challenges you as a project manager to focus on achieving project business value while executing your projects rather than the traditional focus of just being on time and on budget. To do this I introduced the Project Speed2Value Road Map that was developed based on best practices from the Project Management Institute’s (PMI) PMBOK, Six Sigma, Risk Management, Financial Management, and Change Management. Used on dozens of Fortune 500 projects large and small throughout the world, the Project Speed2Value Road map is one of the most comprehensive approaches within the industry specifically designed to manage the full project life-cycle and track ongoing project performance.

Figure 1-1: Speed2ValueTM Road Map

The first step of the Project Speed2Value Road Map is to develop a Project Business case. In doing so you as a project manager will begin to lay the foundation for achieving project success by obtaining buy-in from top management and get your project approved for execution. This means getting the powers at large to give you the required funding, resources and time to execute the project. Sound simple? It is not by a long shot. With chief executives mandating tighter control over spending, financial support for projects comes at a premium. Resources are limited at best, and there is not enough time to do all things necessary to keep the business running smoothly. If you are like the rest of us, I am sure you have put in your fair share of working more than eight hours in a day, weekends, and holidays on occasion. Am I right? Compound that fact by all the employees in your company. Astounding isn’t it? With that said, I am sure that you are not the only one in your company with a good idea for a project. It is a given that every proposed project out there is in competition for the same resources, limited funding and time to be spent by your company for implementation. Therefore, it is up to you to justify that your project is better than the rest of the proposed projects, so that you are one of the few winners getting the limited resources, funding and time commitments from the powers that be. The key to getting your project approved is your ability to prove that your project, among all others, will deliver business value to the company. This means that you must be able to articulate “how” your project will deliver one or more of the main business drivers: cost reduction, business growth, maintaining operations (e.g. regulatory compliance), increasing speed and efficiency. Keep in mind that these business drivers are why projects are executed. These are the drivers that keep your company profitable and keep your company competitive. Therefore, it is up to you to demonstrate how one or more of these business drivers can be achieved by your project in order for your project to get approved. This is the premise for putting together what is called a project business case.

In simple terms, a business case is a project justification document that outlines a project proposal and plan for authorized funding, resources and implementation. It is a plan for execution and more importantly a plan for achieving project business value. The objective of a project business case is to justify:

  • “what” benefit and cost the project brings to the business
  • “why” the project is important and should be funded
  • “where” the project needs to be implemented
  • “when” the project can be implemented
  • “who” is required to implement the project
  • “how” the project can be implemented with success

A business case is typically mandated by organizational policies and management preferences. The key is that the business case is used to approve a project as well as serve as a baseline for determining project success. Think of the business case as your first benchmark for stating your plan of action as well as measure for success. If all goes right and your project is approved, you will be on your way towards laying the foundation for building a project success plan of action. Like a blue print for building a house, a business case is the blue print for achieving project success. Would you want your house built without a plan? If I you’re going to invest hundreds of thousands of your life savings, wouldn’t you want to see the plan. What type of house it is (3 bedrooms or 4)? Why does it cost so much? Where it is going to be located (facing north or south)? When will it be built? Who is building it (are they reputable)? How will the house serve you and your family in the years to come? Wouldn’t you agree that by answering these questions, you could determine if you want to spend your hard earned money on buying it? The business case for a project is the same thing, but instead of it being your hard earned money to be spent, it is your company’s. Instead of you and your family living in the house for the future to come, it is your company and its employees who will be impacted by the project you propose. As such, the business case is the blueprint for success; it is the plan for a project that will best serve company employees and help make your company more profitable and better off by implementing it. It is therefore up to you to articulate the case why your project will serve the company best and how you plan to make it happen.


Jeff Berman is Vice President of PM tec, Inc.(www.pmtec.com), sought after speaker and author of the best selling book, Maximizing Project Value about developing a winning business case, managing influencers, and the seven principles for business case success. For more than 20 years, Jeff has helped Fortune 500 companies including Gillette, Johnson & Johnson, FMC, CertainTeed and Cytec deliver measurable value from project investments. Jeff can be contacted at [email protected]

 

The Real Costs of Failed Projects

Ever since the CHAOS report of 1994, we have been hearing increasingly more alarming stories of failed projects and their costs to the world economy. Take, for example, the KPMG study published in the UK in 2002 and based on a survey of 134 public companies. According to the report, 56 per cent of them had had to write off at least one IT project in the previous year, at an average cost of US$12.5 M, while the highest loss was placed at US$ 210 million.

That’s around US$1.7 billion for this group alone. You’d expect to find CEOs, boards of directors and shareholder groups hopping mad at this flagrant waste of time and money.

But no! The same KPMG study tells us that only 9% of organizations regard completing projects within budget as their most important success measurement. And just 21% are driven by a need to finish a project on time. You begin to wonder what are their criteria for success, if time and money don’t enter the picture.

That was back in 2002. Sixty-seven per cent of respondents in the survey mentioned that their program management function was “in need of improvement or immature” and only 44% rated project performance against any established measures. I wonder what we’d find it KPMG were to undertake the same study today, five years later.

But let’s go back to the figure of $1.7 billion in project failures that I mentioned earlier. I would submit to you that the number grossly underestimates the financial impact of failed projects. Let me explain.

Self-reporting and the definition of failure

For starters, project performance is usually estimated by surveying managers and executives, often the very people responsible for the failed project they are asked to talk about. It is reasonable to assume that self-reported project failures and the associated cost implications are somewhat muted. That’s is just human nature.

The next question is, of course, what exactly constitutes failure? Is it a project that is admitted by management to be a complete failure? Is it a project that failed to address the full scope?

The latter definition would probably include most of the projects out there, while the former will only include a small percentage of projects, since it usually really takes a spectacular failure for a project to become deemed as such. I am sure many of us have experienced a situation when a barely passable project was proclaimed a huge victory. Sound familiar?

Given this, I believe that the number of failed projects is wildly understated right across the board.

Opportunity costs

Let’s now consider a project on which an organization spent one million dollars and decided to close with no salvage value to its assets or deliverables. What would you say that project cost the organization? One million, right?

Well, I think this is how many failed project costs are reported in surveys. However, this number only represents a small part of costs incurred by an organization when a project fails. I am talking about opportunity costs.

Opportunity costs are the costs of foregoing something given the selected course of action. For instance, if a working individual elects to pursue a two-year university degree full time, the cost of this decision will not only include the tuition and auxiliary fees but also the lost employment income for this period, the latter being the opportunity cost of this decision.

In projects, opportunity costs come in two fashions.

To start with, it is fair to say that projects are often undertaken in order to realize a business opportunity, such as to enter new market, to develop new product or service or to improve existing product or service in anticipation of higher profits. If such a project bombs…none of this will happen. The unrealized business benefits may easily dwarf any direct costs associated with this project.

Then, there is another consideration. No organization can execute an infinite number of projects at the same time. Various limitations exist to prevent that from happening, the organization’s capacity to absorb change being one of them. Because of this, some projects considered by an organization, all with their costs and merits, have to wait their turn in the pipeline. Often, they never come get started because, by the time the organization is ready to execute them, the business opportunity is no longer there. Let’s say project A is executed before project B, but project B is dependent on the success of project A. If project A fails, project B is no longer valid. Thus, the cost of the lost benefits that project B might have delivered should also be counted in the costs of project A.

It is quite clear that lost opportunity costs, however substantial, are not included in reported failed projects’ costs. They are not as easy to arrive at as direct project costs and, frankly, it is simply outside of many managers’ skill set. But maybe it’s time that this capability became part of the manager’s essential qualifications

So, how much are all these failed projects costing the world economy? I think that the number is much higher than what we’re being told…and the exact number of failed projects…will we ever know?

It would sure be nice to find out…maybe the next survey will tell us!


Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc., a management consulting company located in Mississauga , Canada . His 14 year professional career has been devoted to the field of Information Technology. Before starting Bizvortex, Ilya served as a Director of Application Development and Maintenance at Mytravel, Canada . Prior to that, he lead IT projects, designed business applications and managed complex system implementations in the travel, retail and transportation industries. Ilya can be reached at [email protected]

Chocolate or Vanilla

When we go into an organization to do an enterprise project management or enterprise timesheet deployment, there is almost always a wide range of people and departments represented.

The dream scenario is to arrive to find all processes already streamlined and all the chain of command organized and in place. We would deal with one person, who would speak for all parties involved, and who would have already worked out any differences or discrepancies they might have in how to best use the tools we’re arriving with.

Alas, that is a fantasy that is seldom realized!

The more likely scenario is that the project is being promoted by one or two groups within the organization, who feel a burning need for it, and a much larger number of people who feel they will be affected by the deployment, and want to get their requests for functionality or control into the project before early on. This makes deploying a “vanilla” install or a default system less desirable in their eyes.

The clues that this is what we will be facing often come early. A Request for Proposal (RFP) arrives and, as we dissect it to try to determine what the client really needs, we find lists of functionality that don’t seem to have any consistency. There are similar or identical functions listed more than once, but written in a different language each time. There are requests for functionality that are diametrically opposed. (e.g. “All data in the system must be completely centralized.” and “The system must allow for data to be autonomously managed in a decentralized fashion”) When we see this sort of thing we know how the RFP was created: By committee!

For those who may never have suffered through this kind of exercise, you can only imagine how tough it is for the person heading the committee. They have probably been with the project since the early days and are committed to see the new enterprise system deployed within the organization. When the project started it was a small group of like-minded people but, as the project progressed, more and more divergent points of view arrived. Just to construct the RFP, numerous points of view now had to be represented – and this is the document that is sent out to happy contractors like ourselves!

When we arrive to do the work, this can be a tremendous challenge. First, we have several perspectives to satisfy before the project can be declared complete. If we’re doing a timesheet system, we may have the project management department, the payroll department, the HR department, the IT department and senior management, all lobbying for their particular interests. What if some of these interests are in conflict?

So, we start from the vanilla perspective. What would this system look like if it were installed as delivered? The publisher, after all, has likely spent a fair amount of time making sure the system has some usefulness from the moment it’s installed.

This is the baseline install. The closer we can keep to this baseline, the easier it will be to do upgrades, create training material and generally, to deploy the product. The more “vanilla” it is, the more materials we’ll find from more suppliers that can help with training, configuring, third party assistance, and more. The more we customize what we’re working on, the closer it will get to the vision of each of the interested parties. It’s a series of trade-offs that have to be negotiated.

It’s easy to see the result when the implementation goes too close to one extreme or the other. If you go to close to the default install and your users are unlikely to adopt. The system may not be close enough to what’s familiar. If you go too much on the customized side, the system may never deploy. The further you get from the default install, the more effort is required just to get the system functional. Moreover, when you then turn to the publisher for assistance, they’re handcuffed. The system gets to be so far away from the baseline that the technical support people are hard-pressed to know how to answer any questions on it.

So, how far along the flavored path should you travel away from the baseline vanilla?

You can start the conversation at either end and work towards the middle. For an organization that is interested in long-term deployments, the best place to start is at the highly flavored end of the conversation. You’ll find plenty of people in this corner convinced that their way is the best way, and only want to hear how you’ll do it their way. In the ultimate scenario, you’ll be able to place numerous programmers for an extended amount of time to write the perfectly matched EPM or Enterprise timesheet system.

At our firm, what we train our technical people to do is to start at the other end; from the vanilla end of the scale. We start with a default system and then look to justification for each change. We let the client and each faction know that we’re prepared to adapt to anything they require, so that we don’t generate resistance on the first day, but every change needs to have some business purpose. Note that I didn’t say some “functional design”. No, it’s got to serve a business purpose. So, when a future user says “I need a dashboard that shows this data color coded by age”, we ask “What business decision will you be able to make or be able to make easier if you had that?” Often the reply is “We’ve always done things that way” which is not, of course, a good business reason.

A couple of years ago during an EPM configuration, I was presented with a collection of reports and told that the client expected all these reports to be represented in the new system. It was an intimidating list of 212 reports and I’m sure just collecting the report samples must have been a significant task. I looked at the several inch thick pile of paper samples with some dismay imagining the weeks it was going to take us to recreate them all.

My response to the client was this, “We’ll be delighted to do these reports for you. But, first, would you please arrange it so I can speak to the readers of these reports to determine what business purpose they’re used for.”

Needless to say, finding such people was a challenge.

In the end, we did only 12 of the 212 reports. We couldn’t find an audience for the rest. ‘Why were there 212 report samples then?’ you ask. ‘It’s the way it’s always been done and the way we want to do it forever,’ is the answer.

Vanilla, chocolate or any flavor under the sun, are the choices you’re faced with when doing your own EPM or Enterprise timesheet deployment. A little flavor is quite enjoyable but sometimes, vanilla tastes just fine.


Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

Everything You Ever Needed to Know about Running a Project, You Could Learn by Climbing a Mountain

Deciding to climb Mount Kilimanjaro in January 2005 was a conscious decision and part of my life list of goals. It was an experience of a lifetime and certainly has made me view life from an entirely different dimension. And that’s what this kind of experience should do!

In planning, executing, reaching the summit and reflecting back on the adventure I realized the parallels with running a project.

First, you must set goals.

Setting goals in life and on a project are critical as they give us energy, a sense of direction, confidence and a sense of meaning. Simply thinking about them or verbalizing them is not enough. When we write them down they become real. For me, committing the goal to paper – in this case the Kilimanjaro climb – and then starting to talk with others about my decision made the situation very real. That is when the journey to the summit really began. The goal itself had a number of parts: physical; personal development; its application in the work place and generosity (it was a climb for charity). All of these had to be taken into consideration as I began on the next stage, planning.

Personally, I need goals that will stretch me well beyond what I think I am capable of doing. This allows for tremendous growth, realizing I can go much further than I ever thought possible and, along the way, learn as I prepare for reaching my next goal. In projects we need to do the same. With a stretch or a stride we can constantly amaze ourselves and achieve far more than imaginable. Ordinary folk really can achieve extraordinary results.

With a clear and real goal in mind, we must plan.

Mount Kilimanjaro in North-Eastern Tanzania. At 19, 340 feet, Mt. K is the tallest mountain in Africa

Whether it be a project or a personal goal, time spent on up-front planning is crucial and typically pays off with the resulting achievement. In our case, we booked our trip in May 2004 with a departure date of January 15, 2005. This gave us plenty of time to plan, prepare, budget and ensure all of the right components were in place for ultimate success.

Preparation really is everything. It ensures you are ready, willing and able. It provides the means to visualize the end result, giving you an idea of what is needed to succeed. If you are at the bottom of the mountain you have an idea of what it will take to climb. And so you plan accordingly. For our climb we needed to not only train (an average of five days/week for five months including a hike on the weekend averaging four to five hours) but also needed to meet other requirements including shots, medications, equipment, flights and tools. We had to be prepared for the risk factors and ensure contingencies and mitigation strategies were put in place. Wills were updated, cancellation insurance acquired, backup staff were given responsibility for the business while we were away and a route was chosen that would be longer than usual but boasted a higher rate of success at summiting (our ultimate goal).

A brief rest along the way was always welcome, especially as we got closer to the summit and the air got thinnerIn planning we often forget to include flexibility; the concept of re-planning along the way. In other words, you begin to execute your plan and find, through some experience or additional information, that you need to make adjustments in order to assure your ultimate success. With each flag planted up the mountain you have a clearer picture of the end and increased accuracy in timing, what is left to do and the resources to make it happen. Certainly on the climb we faced a number of issues (some expected and others not) that required adjustments to our progress.

Execute and Manage.

Finally the day to leave arrived and we were officially into full execution. It took two days just to get there and a day of acclimatizing before we began the trek. Nervous, anxious (someone had died on Kilimanjaro the day we arrived – about 15 people die annually on Kilimanjaro) and with some apprehension we headed off to the trail and into the rainforest (the first of five different zones we would encounter).

During execution of any project and in climbing a mountain, there are five key tenets I live by. These creeds relate well to our project lives.

  • Strength: Strength helps ensure you are up for the task – fit and on your game. You need strength for the ‘heavy lifting’ along the way. In our case, it was to deal with the extreme verticals, the change in altitude and what it does to your physical and mental state.
  • Endurance: Some days were long and the going can get tough. Having the stamina for those long hauls was critical. We needed to be willing to go the extra mile without necessarily knowing when the end was in sight.
  • Adaptability and Flexibility: You need to adapt to the conditions around you – in our situation, it was weather, terrain, and what happened on the trail. The flexibility to adjust as required is important. While you may have a plan and are executing correctly there is always the chance that change or adjustments will be needed.
  • Risk: Undertaking a trip of this nature is fraught with risks. I needed to be willing to take risk that was well outside my comfort zone. Taking risk allows you to stretch – even to the point of being willing to ‘leap before you look’ – relying on other’s assurance that it will be fine on the other side. Then there are those situations, those unknown risks that pop up, regardless of how well you have planned and prepared your mitigation and contingency plans. This requires trusting your intuition and using your “edge” to break through those barriers and continue on.
  • Communicate: You can’t do it alone. You will always need a team of experts to complement your strong suits and to provide support. Make sure they are right for you, know what they are doing and have the confidence in their capability and competence. Communicate with them – early and often, both up and down the line. On the climb we met each morning to check in with the guides and our team. We discussed our physical situation (how we were feeling) and the itinerary for the day. In the afternoon we met with other climbing teams to discuss their experiences and what was working for them. Communication is essential to key decision making, gaining confidence and knowing that others are facing similar situations.

Crossing the finish line (reaching the Summit).

This part of the journey was beyond description. It was quite spiritual being above the clouds and looking out. We had our moment to reflect on the achievement, celebrate (with a tiny amount of champagne), take mad pictures and finally realize the extent of what is possible. Stretching ourselves forces oneself to step outside of the comfort zone and grow in very positive ways that have far reaching impact not only for our own lives but for those around us.

Contrary to what most would think reaching the summit, while amazing, was not the end of the journey. The true completion was the descent. For projects this is also the case. Often initiatives are celebrated upon delivery whereas proof of whether or not success has truly been achieved often happens the day of use or when put into practice (i.e. a software tool). And like descending the mountain focusing on that component in our project lives is just as challenging.

Take a moment to look back (lessons learned).

Celebration is essential as we achieve our goals. Capturing the lessons we have learned along the way is equally important. The time to reflect needs to be done intentionally and with the future in mind. What worked; what do we do differently and how does it apply to achievement of our next goal? This is the key ingredient to consistent, repeatable success.

Would I do it again? Absolutely! Will I? Not on Kilimanjaro. There are way too many other ‘mountains’ to climb. My life list of goals is rich, long and challenging. If I get to the end then maybe Kilimanjaro will get another visit. For now I am thrilled with the result, the experience and the opportunities to apply learnings to both my business and personal life.

 


Catherine Daw is President and co-founder of SPM Group. A project management pioneer with over twenty-five years experience, Catherine’s expertise spans project management, strategic planning, organizational and operational review, implementation planning and execution. Catherine holds a BSc in Mathematics and Computer Science from Queen’s University and an MBA from York University. She is an active member of the Project Management Institute and is a certified Project Management Professional (PMP), as designated by the Project Management Institute. She has delivered many papers and workshops at a variety of conferences both in Canada and the U.S.A. Catherine is also regularly featured in publications and has sat on various advisory boards over the years.

SPM Group is a leading management consulting boutique focused on Strategic Project Management. Our offering ranges from specific initiatives to total, integrated end-to-end solutions. We work closely with clients to formulate and implement powerful business strategies and have delivered services ranging from managing projects to project portfolio management, from strategic development to strategic execution, from assessments to training to coaching.

 

David Barrett

It was just four years ago when we had some BAs out there, but that was it. No IIBA, no Masters Certificate in Business Analysis, no BABOK (their Body of Knowledge) and no certification exam.

Well that was then and today we have all of that and more. The IIBA is boasting members from all around the world. There are lots of new training programs out there for BAs, and the IIBA has produced Version 1 of the Business Analysis Body of Knowledge and the certification exam.

Should project managers take note? You bet! The role of the BA is fast becoming the key to successful project management. A project manager who thinks he or she can do it all – without the aid of the BA – is old school. And I think the organizations that think the PM can do it all are not only old school, but in danger of loosing good PMs as well.

For years we have been asking PMs what hurts you the most? The answers were always, ‘lack of executive support’ and ‘lousy specs’. The former problem is still a work in progress. The latter should be going away as we type and read. Enter the business analyst. This is the architect – the designer. This is the one who will discover and document the client’s requirements, run through a series of designs and produce the detailed specifications for the PM to build from. Finally!

Where to from here? The role of the BA will become more and more important. The BA will become more senior within an organization. The Business Analysis Body of Knowledge will go through a series of versions over the coming years and soon ‘Certified BAs’ will be in high demand.

And that’s where this Business Analysis stuff is going!