PMNifty!

How to collect signatures for your documents?

June 8th, 2007

At some point in your project, you are going to need to collect signatures for one of your documents. You are getting sign-off are you? I know it can be rather challenging to collect signatures, especially if you have a long list of busy people. In an ideal world, the only signature we need is the project sponsor and the project manager. In reality, the list of signatures could span multiple pages!

So, how do we get signatures on paper? I have a simple process that culminates with the “easy” signatures as follows:

Step 1: Determine who needs to sign

I do this as soon as possible, preferably in the first kick-off meeting with the project team. Simply list the documents that will be produced as part of the project and explain the contents of each document. Ask the customer and the team for the correct people for each of the documents.

Step 2: Keep the list of signatures short

Now you have a list of names. Verify again with the customer and the team – do the signatories have the correct authority and technical knowledge? Do they have dedicated time to be involved to provide input and review drafts? Your aim is to get the list as short as possible, but with the appropriate authority so as not to potentially jeopardize your project.

Step 3: Share the work in progress

You need to keep the signatories involved with the document creation, and get them involved and part of the process as soon as possible. The more input they provide, the more ownership they will feel towards the document. The more you include them in reviews and updates, the more they will feel confident with the contents and the fact that they have provided input along the way.

Step 4: Review

When the document is ready for sign-off, schedule a review walkthrough. I like to put the document on a projector. Do not print copies for everybody as people will start browsing back and forth without focusing on the current section. With you projecting the document, you control the flow and it focuses the team on the current section. Walkthrough the document with everybody by high lighting and paraphrasing the document. Do not read the document out aloud! The idea is show the contents, but verbally paraphrase to refresh everybody’s memory. This should not take very long, 30 minutes to 1 hour depending on the size of the document. This process, although it seems a bit stupid, actually works extremely well. It allows the signatories to review the document with you, and provides for another opportunity for comments and updates to the document. If there are no changes to the document, pass a printed copy around the table and get the signatures. If needed, you can handwrite small changes directly on the document and sign them off all in one go. If there bigger changes are needed, move to step 5.

Step 5: Get the easy signatures first!

Update the document with all the changes. Once you are confident that the document is good to go, collect the easy signatures first. It can be incredible intimidating for the first person to sign the document because “Nobody else has signed, I’m not too sure about this” syndrome. You need to collect the “easy” signatures first e.g. your signature, your account manager, and team members. When presenting a document that is already signed by two or more people, it is way less intimidating for that person to sign - “If other people of have signed, then it is safe for me to sign as well!”. As you start collecting more and more signatures, the process with go smother and quicker until you have them all!

What tricks do you use to get signatures? Leave us a comment and share your thoughts!

Posted in How To | 1 Comment »

What is the difference between duration, work, effort, hours, and man-days?

June 5th, 2007

I come from the Microsoft Project world where schedules are built using duration and work. However, ever so often team members refer to effort, hours, or my personal pet peeve – man-days. What are all of these and how do they compare?

My nonprofessional definitions are summarized as follows, with examples below:

Duration – the amount of time it takes to complete a task. Measured in days, from task start to task end. Can also be referred to as calendar time.
Work – the amount of hours it takes to complete a task. Measured in hours, from task start to task end.
Effort – the same as work.
Hours – the same as work.
Man-days – the same as work, but expressed in days instead of hours.

To illustrate, we will use a simple example: We need to build a wall.

Example 1: Duration

The wall will take one builder 10 working days to build. In Microsoft Project, this would be represented as follows:

Duration is 10 days
Work is 80 hours (Assuming the builder works 8 hours a day, that’s 10 x 8 = 80 hours)
Effort is 80 hours
Hours is 80 hours
Man-days is 10 days. Be careful! Man-days is not the same as duration. See the next example.

Example 2: Man-days

The same wall will take two builders 5 working days to build.

Duration is 5 days
Work is still 80 hours (2 builders, each working 8 hours a day for 5 days)
Effort is 80 hours
Hours is 80 hours
Man-days is 10 days

Example 3:

We have two builders, but the client will only allow us to work for 4 hours in the mornings. Thereafter, we need to leave the building site. The same wall will take the two builders 10 working days to build.

Duration is 10 days
Work is still 80 hours (2 builders, each working 4 hours a day for 10 days)
Effort is 80 hours
Hours is 80 hours
Man-days is 10 days

In Summary:

When team members start using non-standard terminology, make sure that you understand exactly what they mean. When quoting customers on a time and materials basis, work is the only reliable source – in the examples above, work remained at 80 hours regardless of how the work was resourced. Wherever possible, I always refer to Duration and Work. These are two “standards” that most other Microsoft Project users will be familiar with. Leave a comment and let me know if you found this useful.

Posted in What is? | 4 Comments »

How to create a weekly project status report

May 29th, 2007

Great project managers communicate regularly and on a predictable basis with their teams and stakeholders. One form of communication is a weekly status report.

Instead of creating a report consisting of pages and pages of feedback, metrics, tables, graphs and project registers, I find that a simple report, sent on a predictable schedule is the most effective approach. Let us look at this in a little bit more detail.

Simple

I send my status reports as an e-mail. Not as a document attached to an e-mail, but the contents of the reports is the e-mail. Furthermore, the report is no longer than one page as anything more will most probably not be read. The idea is to provide the team and stakeholders with a short, but concise and accurate report on the status of the project. They just need the reassurance that the project is being managed!

Predictable schedule

When you distribute the weekly status report on predictable schedule, you create the impression that the project is under control and in a subtle manner, that the project is also predictable. I pick a date & time for when my status reports are e-mailed, say Friday morning at 08h00. Then I create the status report the day before, on Thursday afternoon, and schedule Microsoft Outlook to send the report at 08h00 on Friday. Thus, every Friday at 08h00 the stakeholders and team get their predictable report. Fantastic! The great thing about the predictable schedule, especially if you manage a portfolio of various projects at the same time, is that they force you as a project manager to stay very close to all your projects.

So, how do we do this? You can follow along with the following Microsoft Word template sample:

Template Download

Weekly Status Report

An example of a weekly status report

For all projects, there are two things that I believe must always be on the report:

Progress
Planned for next week

These should be simple commentary that you type up, a few sentences that tell a story of the progress made this week, and what the team is planning for next week. If this is all the stakeholders read, excellent! They will have an idea of what you have accomplished and what to expect from you next week. For example:

Progress: All analysis is complete, the IT infrastructure has been deployed, and the solution configured. We have completed the Human Resources data migration and were able to fast-track the Manufacturing data migration to meet the monthly shutdown deadline.
Planned for next week: Complete the development of the reports for Human Resources, provide “at-the-desk” training for the Human Resources manager, followed by “Essentials” training for 11 staff members.

For a small project, that is all that I would include on the report. For larger projects, I go into a little more detail but stick to the “keep it simple” theme. So larger projects will see the inclusion of basic cost metrics (budget, actual cost to date, cost comments), schedule metrics (actual percentage complete and schedule comments), the top 3 risks, and the top 3 outstanding issues. That is it, nothing more.

I am sure that many will argue that more information should be included. What about milestones, deliverables accepted, actual vs baseline vs forecast metrics and the project registers? The thing is, most stakeholders will not read (and understand) all of that. In the rare circumstance where extra information is requested, you should provide it immediately.

Tell me what you think about this article, the approach, and the sample template. I would love to hear your feedback and comments!

Posted in How To | 5 Comments »

How to create a folder structure for your project documentation

May 27th, 2007

Do you know where to find a specific project document? Does your team know where to find documentation? Once you have found the document, how do you know it is the right version? Which version does the customer have, and which version is your team using? Having a standardized approach for project documents solves these issues and is great time saver, regardless if the documents are organized on your notebook, network server or an online collaboration tool like SharePoint team sites.

A folder structure that works for most people is one whereby projects are grouped by customer as in the following example:

The project folders themselves can take several approaches, and it depends on the size and nature of your project. In the two examples that follow, I will show you an approach for a small project, as well as for a larger Microsoft Solutions Framework (MSF) project and a PMBOK® project.

Example 1: The small project:

I use three folders as follows:

The three folders have very specific uses. The project team has read and write access to the Work in Progress folder. As the name depicts, this is where they keep documents and project deliverables that are in development. Once a document has been reviewed internally and is ready for distribution, the project manager moves the document to the Baseline folder. While the project team has read access to the Baseline folder, only the project manager can write and change documents in the Baseline folder. If a previous version of a document exists in Baseline, the project manager first moves it to Previous Versions. This seems a bit over the top, but it’s actually a simple system and works very well.

Let’s look at a practical example:

Mark has read & write access to the Work in Progress folder. He creates a new document called “Requirements v0.1.doc” and saves it to the folder. Over time, Mark continues to edit and grow the document until it is ready for internal review. Once the document is ready to be shared with the customer, the project manager moves the document to the Baseline folder and renames it to “Requirements v1.0.doc”. This I call the first release to the customer.

The customer reviews the document provides valuable feedback. Mark copies the previously baselined document to Work in Progress, renames the file to v1.1 and then incorporates the feedback and changes. After internal review, the project manager needs to do two things: Move the previous v1.0 baseline document to Previous Versions and then move the new v1.1 document to Baseline and rename the document to v2.0. This is the second release to the customer.

Example 2: The large project:

For larger projects, the folder structure can be expanded to provide another level of categorization. One approach is to create folders according to your project phases, and for each of the phases implement the Baseline, Work in Progress and Previous Versions approach mentioned in example 1. Such a structure could look like the following:

In this example, the MSF phases are pre-fixed with numbers (01, 02, 03… etc.) to keep them ordered correctly. Instead of using project phases, another approach is to create folders for the PMBOK® Knowledge Areas as in the following example:

Again, thee folders are pre-fixed with numbers that correspond directly with knowledge areas within the PMBOK® guide!

Baseline, Previous Versions, Work in Progress:

You may have already noticed, but in each iteration of the folder structure the concept of Baseline, Previous Versions and Work in Progress folders is re-used. These three folders helps the team control documentation (via the folder permissions); provides a standard way of producing, issuing and maintaining project documents; and finally, it ensures that all team members are able to access and work with the latest published documents!

No approach is perfect. How do you organize your project documentation? Let me know what you think, I would love to hear your feedback!

Posted in How To | No Comments »

How to create a Work Breakdown Structure

May 26th, 2007

I find that a well-crafted Work Breakdown Structure can be invaluable on a project. Ideally, I create a WBS as soon as possible, preferably while the sales team is still busy proposing the solution to a client. Using the approach I recommend below, the WBS clearly depicts the deliverables the project will produce, and the activities required to create those deliverables. This benefits everybody from your internal team members, to the customer and other vendors involved on your project. If the teams can visualize the actual deliverables, and how we are going to get there, we are one step closer to project success.

However, any WBS structure will not do. Creating a shopping list of 100’s of activities is just plain stupid. I have done this before and you end up spending all day trying to keep your schedule up-to-date instead of actually managing the team. A WBS should be kept simple, but have sufficient detail to provide accurate cost and schedule information.

So, how do we do this? Decompose a WBS by starting with your phases, then deliverables, then activities. Add milestones, throw in a splash of color, and that’s it! Let us look at an example by assuming that we are working on a software development project using the Microsoft Solutions Framework (MSF) approach. You can follow along with the following Microsoft Project template sample:

Template Download

WBS Decomposition Sample

An example of a WBS decomposed with phases, deliverables, activities and milestones.

Step 1: Define your phases.

Envisioning
Planning
Developing
Stabilizing
Deploying

Step 2: Add deliverables. List the specific deliverables that each phase will produce. It is important to keep this limited to tangible deliverables such as documentation, services. The PMBOK® guide defines a deliverable as “Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project”. By adding deliverables, our WBS grows a bit.

Envisioning
- Kick-off Workshop
- Vision/Scope Document
- Project Structure Document
- Risk Assessment Document
Planning
Developing
Stabilizing
Deploying

Step 3: Add activities. Next, we add the activities required to produce the deliverables.

Envisioning
- Kick-off Workshop
  - Prepare Workshop Materials
  - Conduct Workshop
- Vision/Scope Document
  - Interview Stakeholders
  - Create Document
- Project Structure Document
  - Create Document
- Risk Assessment Document
  - Conduct Risk Identification Workshop
  - Create Document
Planning
Developing
Stabilizing
Deploying

Step 4: Color Code. I am bit of stickler for “making this pretty”, but adding a bit of color to the WBS goes a long way to make large plans simpler to read and easier to navigate. I use the following colors:

Phases in Purple
Deliverables in Blue
Activities in Black (default)
Milestones in Green

The result is as follows:

Step 5: Sanity Check. Next, make sure we are not mad. Review the WBS with your customer, the team, architects, developers, managers. Are the deliverables correct; is there anything missing; or are there deliverables that can be removed? Check the activities to ensure that they cover the major work required to create each of the deliverables. What does this approach give you?

A simple breakdown of Phases, Deliverables, and Activities
The ability to manage deliverable expectations. With this approach, all project deliverables are explicit stated in a plain and clear manner. There are no assumed or implied deliverables.
A sound starting point for the next set WBS activities that cover duration and effort estimation, dependencies and resourcing.

In the next article, we’ll expand this WBS and start our schedule development. Tell me what you think about this article, the approach and the sample template. I would love to hear your feedback and comments!