The Template Collective Blog

Project management templates… and more

Monthly Archives: September 2017

Uncategorized

The Customer May Not Know Enough to Completely Define the Project

Sometimes the project manager places too high an expectation on the amount of foresight and vision that customers and sponsors have. In many cases, the project manager will go to the customer looking for answers to help define the project and the customer will not have all of the information needed. This happens all the time and it does not mean that the customer does not know what they are doing. In many cases, especially for large projects, the customer has a vision of what the end results will be, but cannot yet articulate this vision into concrete objectives, deliverables and scope.

There are three approaches for when you don’t know very much information on the nature of the project.

 

Increase Estimating Range Based on Uncertainty

Based on having less than complete information, the  project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining. On a normal project, for instance, you might estimate the work within +/- 10%. On a project with a lot of uncertainty, the estimating range might be +/- 50%.

 

Break the Work into Smaller Projects

Another good alternative is simply to break the work down into a series of smaller projects based on what you know at the time. Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You can define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables.

 

Uncover the Details as the Project Progresses

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

This last approach uses an Agile philosophy. Agile projects are generally exploratory. The details of the project are uncovered as the project progresses. (There are many more differences in Agile projects, but this philosophy is one.) In a traditional project management model this would also be known as ‘progressive elaboration’ – which also means more details are uncovered as the project progresses.

Uncategorized

Four Responsibilities of Executives on Projects

A Primer on Processes and Templates

Recipes for cooking are a beautiful thing. A recipe tells you the ingredients and how much of each you should include in whatever you are making. It then describes what you need to do to these ingredients in order to make a dish that is not only edible, but tasty as well. It’s great that someone else has already spent the time in putting together a recipe to follow that nearly guarantees success each time.
To a certain extent we use recipes in our profession as project managers. The recipes we follow are the processes and templates that guide our projects to success each time. How can you put a process together and make the most of templates? Consider the following:
A Primer on Processes and Templates

Start with Phases

To put a process together, a good starting place is defining the major phases in which a project must go through. Think about how a project moves through your organization, and document those major steps. For example, a simplified software development approach would include the following phases: Planning, Design, Development, Testing, and Implementation. These phases are the framework in which you begin filling in details about the process.

Move on to the Outputs
The next area to concentrate on is the outputs, or end results, from each of these major phases. Ask yourself what tangible deliverable needs to be complete by the time you finish the Planning, Design, or Development phases. Focus on tangible results, or something you can see, touch, perform an action on, or feel. For example, the Planning stage is going to be filled with meetings and conversations that by themselves do nothing to move the project forward. However, the approved Business Requirements Document is an invaluable output that can propel the project forward to the next Phase of Design.

Back up to Inputs

Now that you have the tangible end results (or deliverables) of each phase defined, ask yourself what needs to be present at the beginning of each phase to create such results. Continuing with our example above, the output of the Development phase would be software functionality that can be tested. In order to accomplish this, the engineering team will need High Level and Low Level design specifications as Input. This will allow them to know not just what they are going to build, but more importantly, how they are going to build it.

Establish Conversion Activity

You now have the Inputs and the Outputs for each of the phases of your process. The final step is to determine what needs to be done to convert the Inputs to Outputs. Think about it this way…what has to be done to change the gooey mess of runny batter into a cake? You need to bake the cake. There’s your conversion activity. Likewise, what do you need to do to convert software that is ready to be tested to software that is production ready? You need to create test plans, execute test plans, and document the results.

What About Templates?

Templates are incredibly useful for all areas of process you create. You can use templates for your inputs (i.e. Business Requirements Document), your Outputs (i.e. an approved User Acceptance document from the customer) and all points in between. Create templates that will provide consistency and make it easy to transition from one phase to the next with confidence.

One word of caution when it comes to process and templates…don’t overdo it! Create just enough process and documentation around your project to float the boat. It can be tempting to have a process or template in place for every little thing. Resist that urge. Remember, too much of a good thing can ruin a good thing. Stick to the recipe and you’ll be able to guarantee consistent results time and time again!