Tag: Requirements

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]

 

In the last few months I’ve had occasion to come across some project management difficulties that have everything to do with perspective.  We rarely consider the point from which we create our point of view because we live inside it.  Our perspective is often how water is to a fish.  We swim through it all day but never really notice or declare it’s there.  Yet not acknowledging that our point of view is really coming from our perspective can cause tremendous difficulties in a project and opens a massive blind spot.

 

Why does this matter?  Because no two people have the same point of view.  When you think of looking at something, you can get right next to someone and see things from almost their perspective, but it’s not exactly the same.  Their head would have to be displaced for you to see things from where they were.  Yet, if we do just that, move their head and move your eyes to the exact spot they were in, it’s already a different time.  Time counts too in a perspective.  So if we can never see things exactly the way someone else sees them, how do we communicate effectively at all?  We can allow for a perspective by declaring our point of view. 

 

In the absence of realizing that everything we perceive comes from our own particular point of view and that our perspective is unique, people are left with saying “that’s the way it is” rather than “that’s the I see it”.  Is this just semantics?  It very definitely is not.  If you say “that’s the way it is,” then it allows for no other interpretations.  You’ve declared that the universe is that way, there is no other and that’s the end of the discussion.  If, however, you say, “that’s the way I see it” you’ve made room for at least one other perspective.  Someone can now say “I see it somewhat differently”.  When this happens, you may be surprised.  ‘How could someone interpret this differently?’ you may ask yourself.  Your eyes suddenly open as you realize that perhaps there are yet other interpretations that you’ve not considered.

 

In the world of project management, being able to identify a perspective as a perspective is a critical skill.  In any project, schedules and scope are often identified by the shortest of descriptions.  Four or five words in a schedule may be all the description of scope that a task has.  This isn’t any problem if everyone understands the same thing by those four or five words but that’s rarely common.

 

Much more likely is that everyone who reads those four or five words has interpreted them differently. 

 

“Write process documentation” is a description I saw recently in a project in which we were involved. 

• The new consultant read these three words and imagined a document that would be two or three pages in length. A title and sentence for each element of the process would be plenty, he figured. A total of four hours would be sufficient to the task, he thought.
• The project manager envisioned a document of 20 or 30 pages. A page per process would be required and a flow diagram of each process would headline each page. The document would have to go to internal review after one draft and then client review after a second. The work would take about 10 days.
• The client envisioned a manual of about 200 pages. Each process would be a chapter. The flow diagram would headline the chapter, there would be a brief synopsis and then the process would be described in a step-by-step fashion complete with screen shots using their own data. The client expected that this manual would be done naturally as the project evolved, with a new chapter added as each process was created. They saw a review period of 10 days as about right for reviewing the manual once completed.

 

Needless to say when the documentation was written, everyone was upset.  When the project manager tried to describe what they had done, the client was shocked.  That wasn’t “proper” documentation,  the PM was told.  The consultant too was upset.  They’d figured the work they would have to do would be a short description.  They’d been obliged to go back to each process and design a flow diagram and a lot more detail. 

 

“Create a link from product A to product B” was a description we found in another project recently.  Despite the documentation that the client had seen, and a demonstration that they’d attended they were shocked to find out that the link created between the two products needed to be triggered by an action by a user.  ‘How could anyone call this a link if it wasn’t “automated”?’ they asked.  When it was pointed out that the client had both seen the link working and seen the feature description of this link, they explained that they’d assumed they weren’t seeing the whole picture because “of course” any link would be automated, wouldn’t it?

 

It’s about perspective.  Everything we’ve ever experienced adjusts our perspective and if you don’t at least acknowledge that there’s no such thing as an unbiased observer, then what you’re most likely to encounter are problems with scope and problems with estimates.

 

Project managers hold a pivotal position in the success of the project.  Regardless of the level of authority of a project manager, they are virtually always considered a facilitator for the communication between those who will do the work, those who will consume what is created and those who will manage the people and the work.  Communication skills are critical, of course.  But, in my opinion, an even more critical skill is being able to identify the point of view of each player in the puzzle.  This is partly why Collaboration has been identified as such an important aspect of Enterprise Project Management.

 

So, how do you mitigate the risks of an inadequate appreciation of perspective?  Start by working on your own perspective muscle.  Learn to challenge your own “isisms”.  When someone says “the way that it is, is…” challenge the assertion, even if it’s just to yourself.  If you catch yourself saying “that’s the way it is,” work on catching yourself.  A book that helped me in this area is from Edward de Bono and is called the Six Thinking Hats.  It’s a classic and is easy to find.  The book deals with how to generate creativity and perhaps that’s a good skill for project managers also.

 

If you’re looking for more practical techniques to avoid the kinds of examples we see above, take a page from the Defense and Aerospace folks.  Project managers who works in those environments have had requirements to include two documents that are essential parts of any mega-project bid.  They are the SOW (Statement of Work) and the BOE (Basis of Estimate).  They’re the bible for anyone doing project work in these environments, because they are a requirement and they identify in much more explicit detail what is meant by the short scope description that we’d normally see in a task name.

 

In the end, if you’re capable of at least identifying your own perspective when you describe something to someone else and acknowledging that they may have their own perspective, you’ll already be ahead of almost everyone.

 

 

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]