Good Requirements vs. Rework

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business. Read more »

Communicating Project Scope

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

The Scope Document

Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important. Read more »

Earned Value Reporting – Estimate to Completion

In this article on Earned Value Reporting we’ll look Estimate to Completion. As explained in the book “The Project Management Question and Answer Book” by Newell and Grashina, the Estimate to Completion describes the expected cost needed to complete all the remaining work for a schedule activity, work breakdown structure component, or the project.

Newell and Grashina’s book is the basis for much of the information in this discussion on Estimate to Completion.

What is the estimate to completion?

The estimate to completion or the ETC is an estimate of the additional money that will be necessary to complete the project. It is calculated from the estimate at completion that we discussed previously.

The estimate to complete is something that can and should be derived as quickly and as early in the process and/or life cycle of the project as possible because it will help the team budget accordingly. However, if the estimate is done early and there is a need at some point to modify it, this can be done once or – if needed -even more than once during the life cycle of the specific project in question.

Can you get into trouble with estimates at completion? You bet you can. As we have seen in the discussion of the EAC, there are many ways that this estimate can be made. The most common form is the budget at completion divided by the cost performance index. This is only a rough estimate of what the project will cost when it is completed.

Using the estimate at completion predicts that the project will overrun or underrun its budget at the end of the project. While it is a good thing to keep the stakeholders and the managers of your company informed that projects are in trouble, it is a weak support for asking that the project be given additional budget. A good project manager who wants to keep his job will take the EAC and use it as additional supporting information to show that the project budget was originally overor understated. In addition to the EAC, the project manager should have much supporting information as to why the project is in the condition that it is in.

Book Review – The Lazy Project Manager

Just as over the past few months, at the request of the Arras People, I am bringing you their October book review.  This time, it’s “The Lazy Project Manager” by Peter Taylor, who now also write for PM Tips.  The book review was authored by John Zachar.  John’s views of the book that he expresses as part of this review do not necessarily reflect the views of his employer, APM.

Book Review – The Lazy Project Manager

Peter Taylor, available through Amazon

Review by John Zachar, APM

It is extremely unusual for me to pick up a ‘management book’ involuntarily. I think I lost that particular desire when I did my MBA in the nineties. However, occasionally there is a need to acquire additional information or background knowledge.

So it was with some trepidation that I picked up Peter Taylor’s book one Sunday afternoon, knowing that I’d promised a review. I finished it later that day, having only put it down for a meal. I really, really enjoyed it.

I’ve read a number of the ‘jokey’ type of management books over the years; those that have catchy titles, and purport to be a fun read, yet seem to be. This time I was pleasantly surprised that the book not only caught and kept my attention, but that it did it in a very enjoyable, easily absorbed way.

Peter’s use of analogies and stories is where I found some of the value. The remainder of the value came in the real content of the book. Over the years as a project / programme management consultant, lecturer, teacher and practitioner, I’ve built up a pretty good education about how to manage change into organisations through projects. I cannot find fault with any of Peter’s recommendations – especially the bit about being lazy!

Peter has been able to enrich the content by using his stories and analogies to make a number of points, all of them common sense; even things like “it is important to separate the important from the immediate” (my words not his – you find his analogy in the book).

One of the analogies that Peter uses, almost from the outset, is that of a dinosaur – in fact a brontosaurus. “I’m sure you know the one, thin at the front, thick in the middle, then thin at the other end.” Well, Peter modifies the analogy a bit by saying that projects should be thick at the front, thin in the middle and thick at the other end again.

The thickness of the project shape represents the amount of effort or work that needs to be done at that stage of the project. The corollary is: initiate well, compensating for difficulties, be lazy in the middle because a well organised project can run on its own like a well oiled machine if initiated well, then put some effort into finishing with real enthusiasm, helping all the stakeholders realise how well it has gone, and what a wonderful result we have.

Organising your project in this fashion allows you to apply the principles of being a lazy project manager – and still be successful. That is really what it is all about.

Don’t forget: this is not about just being lazy and not doing the job – this is being lazy, and being successful as well. Do the job, but do the job in the most intelligent way you can, so that you can be lazy when you can. That is my kind of project management. The other bits that are interspersed throughout the book are about how to achieve the above by using a great deal of common sense.

Peter’s book made this entertaining, yet useful for me.

This article originally appeared in the October edition of Project Management Tipoffs, the project management issues newsletter from Arras People. Subscribe to Tipoffs today.

ABOUT THE AUTHOR: John Zachar is the Product Development Manager with the APM. He has previously written for both Tipoffs and How to Manage a Camel, and would love to hear your feedback. Feel free to contact John with your thoughts about The Lazy Project Manager at john.zachar@btinternet.com. This review is the work of Mr Zachar and is no way connected to any views, beliefs or opinions of the APM.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.