Project Management Templates

Over the past several couple of weeks I’ve discussed many project management-related templates and documents that are commonly used. And along the way over the past 10 months there have been a few other templates and documents discussed.

In an attempt to provide a one-stop document to link to all those templates and documents discussed so far, I’m going to pull them all into this article as a list with available links. Hopefully, having the accumulated list available in one place will be helpful to our readers.

Again, not all of these will be links to templates…some will merely be links to documents that have been discussed in greater detail in previous articles.

• Statement of Work
• Project Status Report
• Communication Plan
• Communication Plan
• Risk Management Plan
• Lessons Learned
• Lessons Learned
• Requirements Traceability Matrix
• Market Analysis
• Project Management Methodology
• Quality Management Plan
• Project Request Document
• Project Charter Document
• Business Case Document
• Change Order Request
• Change Order Request
• Resource Request
• Onsite Visit Progress Report
• Procurement Plan
• Lessons Learned Survey
• Disaster Recover Plan

Summary

As discussed in most of these articles, if having the actual template in a Word doc format would be helpful, just let me know and I’ll be happy to send it to you if I have it. In some cases, I may be able to send you an actual example document from a real project allowing you to better see how I’ve populated some of the information with meaningful data. I’ll revise and republish this article as I make more templates and documents on these and similar topics available that I think would be useful to our readers.

The Project Charter Document

As I discussed previously, I want to bring the readers of PM Tips as many useful…or at least semi-useful…project related documents, samples and templates as possible.  This is a place for new and experienced project managers to gather and share ideas, so I’m sharing.  If any of you have samples that you’d like to share – send them to me and I’ll summarize and post them on here.I have to admit, I’ve not had much occasion to create a project charter document.  Eric Verzuh’s book “The Portable MBA in Project Management” describes the project charter document in this way…

“A project charter announces that a new project has begun. The purpose of the charter is to demonstrate management support for the project and the project manager. It is a simple, powerful tool, but it is not necessarily complex. As an announcement, it can take the form of a memo, a letter, or an e-mail. It contains the name and purpose of the project, the project manager’s name, and a statement of support from the issuer. The charter is sent to everyone who may be associated with the project, reaching as wide an audience as practical because its intent is to give notice of the new project and the new project manager.”

A few years ago I created several templates that I’d like to share with you here over several upcoming articles, including this Project Charter document.  They are merely a basis to get started – I’ve modified them all when I use them in order to fit the specific project or needs of the customer, but they at least provide a starting point.  Again, if you have templates or samples you’d like to share here, let me know and I’ll do my best to get them posted for our readers.

PROJECT CHARTER

[Save file name as: client name PROJECT CHARTER yyyymmdd]

PROJECT BACKGROUND

Provide a brief description of the situation that has initiated the project.

PRIMARY OBJECTIVES

Describe the objectives of the project – “SMART”: Specific, Measurable, Achievable, Realistic, and Time-Based.

ASSUMPTIONS

Describe the initial assumptions under which the project will be to perform.

CONTRAINTS

Describe the scope/cost/ time/resource constraints under which the project will be to perform.

IDENTIFIED RISKS

Describe any known risks which will need to be addressed with the project statement of work.

APPROVAL

IN WITNESS WHEREOF, the parties have agreed to the Project Charter on the date or dates indicated below.

CLIENT APPROVAL

________________________________

VENDOR APPROVAL

________________________________

Project Management: Back to Basics

We write about a lot of different topics about or relating to project management on this site. Experiences, mistakes, successes, job openings, fascinating books, and informative articles. And, of course, fundamentals.

I’ve shared a lot of stories over the past few months – experiences from my past trying to relate them to sound project management principles…or lack thereof. I believe that every now and then we need to step back from the discussion of experiences and accomplishments and re-focus on good sound fundamental project management. My wife would probably say nothing could be more boring…but since I’m writing and she’s not, it’s my choice what I write about!

How We Get It Done

Whether you’re managing a construction project, an IT project, a landscaping project, an accounting project, a process re-engineering project, a remodeling project, or basically any other kind of project, the basic fundamentals are still the same.

We utilize, in some form, at least all of the following 5 steps – possibly more – to get from project inception to project deployment:

• Statement/Scope of Work
• Define Requirements
• Design/Develop
• Test
• Implement

Statement/Scope of Work – You start with a scope of work (SOW) that represents what someone needs…that could be you, your organization, an internal customer, or an external customer…but it’s contains information that documents a need.

Define Requirements – Once the SOW is fully documented and understood by all parties, then you can define the requirements in detail. This usually requires a thorough understanding of the following:

• How things work now
• How things need to work at the end of the project
• Why the need is there
• How the solution will be used

Other concerns at this point may be risks that one can envision possibly presenting themselves during the course of the project. It’s important to fully analyze those potential risks, document how they can be avoided or mitigated should they arise and keep checking them regularly throughout the project.

Design/Develop – Next we actually design and develop the solution. These sound like IT terms and they are, but they can apply to construction where we design and build. In landscaping one would design and then build, plant, dig, resurface, etc. However you look at it, this is where you go to work and start to create what the SOW and requirements said you would do.

Test – Once the solution is ready, then it’s time to test. In IT, this is truly testing. In construction, this would correspond to inspection. This is where the customer – whoever that may be – runs through the solution and gives approval or sends you back to perform more work.

Implement – Again, for an IT project, we usually call this ‘deployment’ or ‘implementation.’ For construction, it would probably equate to the final walkthrough. No matter what the industry, implementation is the final step – other than support (or warranty work) – for the delivery organization. This is where the planned solution that should meet what’s outlined in the SOW and documented in the requirements definition, is handed over to the customer ready for processing or usage or occupation, etc….depending on the industry.

Summary

I realize that this probably over-simplifies the process a bit, but we’re trying to write not only for the experienced project managers and other delivery team members out there, but also for aspiring and new PMs that may be part of an organization with no mature process wrapped around project management. Everyone started in PM somewhere – and in smaller organizations there may just be one PM with the responsibility of coming up with all the plans, templates and processes on their own and trying to make the practice work. It’s imperative that we periodically break it down to the simple details of what we’re trying to do.

In an article in the not too distant future…possibly in the next week or so, I intend to provide as many PM-related templates as I can find that I have in my possession. If PMs out there are like me, when a need comes up for a particular plan (like a risk management plan, etc.), you end up scouring the internet for a sample to take, modify and make your own. Hopefully, I can help you all with that process by providing what I have and thus giving you one more sample to choose from.

So How Did You Become a Project Manager?

I’d really like people to answer this one for me….so please get ready with your comments. It’s a much more recognized field now than it was 20 years ago so you now actually see people getting degrees in project management and planning a career in it. But that definitely wasn’t the case 20+ years ago – at least not for me. What’s your story? I’d like to hear it and everyone else probably would as well. Tell us. Here’s mine.

How Brad Egeland Came to Be a Project Manager

Ok, this is not going to be an adventure story – that’s for sure. Some of you may already have heard some or all of this before because I think I’ve already included some info about this hidden in a past article somewhere. But, for the new readers or the ones who just can’t get enough of this info (yeah, right?)…here goes…

My father came straight out of college and started the IT department in the 1950’s for a large Midwestern grocery store chain based in my home town. I told him growing up that I was not going to have anything to do with computers. I even continued that stance as I started working for him after I turned 16 as a computer operator running card decks through card readers and loading large backup tapes on tape drives (and lots of mischievous things late at night in the warehouse involving the golf carts that the security guys would use to go from station to station….ah…good times!).

In fact, I was going to be a pharmacist (why?). I even started out in pharmacy my first year in college. Nothing against pharmacists…my brother is a pharmacist…but that just wasn’t for me. I moved over to the business/MIS track and took one – count ‘em – ONE programming class…COBOL. That landed me my first job right out of college in the mid-80’s as a COBOL mainframe programmer and guess what, I was doing something with computers. My dad was right…again. Oh well.

Application Developer

I quickly became a system lead on a large government contract – the organization I worked for primarily bid on and won large education-related government contracts. We’re talking in the $100-200M range lasting 3-5 years. So there was a lot of opportunity for responsibility fast…and a lot of opportunity to play significant proposal roles in winning new contracts…which led to opportunities for new roles on the new contracts.

First Manager

I also should mention that I had a great friend and manager at the time – he’s now a CTO in Minnesota, but he was a great career mentor to me back then and could see I wasn’t the type who would be happy coding 8-10 hours a day forever. He helped me shift gears, move into proposal roles and then into roles on new contracts that placed me in line with program and project management responsibilities. My first move from development was to a configuration manager role on a new contract our company had stolen from the incumbent.

From there I moved into multiple project administration roles (managing program budgets, change orders, configuration/change management, and financial forecasting) on contracts before accepting a key contract position as a Deputy Project Manager on a 5 year education contract. This was my first true ‘management’ role with actual hiring/firing/etc. responsibilities over resources – and also made me the youngest true manager in the history of the company at that time. That’s changed since then as they’ve grown and the need for actual managers has grown as well.

The Big Jump

Since moving into the role of Deputy Project Manager in the early 90’s I’ve had various PM and PMO roles and responsibilities – my last 18 years have all been filled with project management and PMO leadership roles. The organizations have changed, the industries have changed, the types of customers I’ve served have definitely changed, but the principles that guide me in my PM work have remained the same – those characteristics of a project manager are applicable to whatever customer, industry or company you’re working with. Methodologies, templates and processes get tweaked, but the fundamentals are usually about the same….organization, timely reactions, ownership, honesty, stubbornness, willingness to lead, etc. Those things remain the same – and continue to drive me down the right path to this day.

Well, that’s my story…were it not for an ill-conceived route through college starting with chemistry classes and ending with system design classes and a good mentoring manager as my first supervisor, I may not be here, but I’m glad I am.

Tell us your story…

Taking Steps Toward Better Resource Management

This post is basically the intended “Part 2” that I never got around to back in February when I published “Project Management and Startups: Resource Allocation and Usage – Part 1.”

In all of my years of Project Management one of the most frustrating parts has been managing resources. It’s hard enough managing resources on your own project or projects, but the bigger issue is that usually those resources are working on another project as well. And here I’m only talking about the ‘people resources.’ These are the living, breathing resources that can tell you what they’re doing and the other projects they’re working on for other PMs. At least when you hear it verbalized like that, you can do so compartmentalizing in your head of what they have going on, what their current priorities are, and what their general availability is to perform next week’s critical task for you on Project ‘Y’.

When you’re dealing with equipment resources, then you’ve brought into view an entirely different variable…and problem…that makes resource management an even more difficult task. Equipment resources can speak for themselves, don’t understand what critical tasks you have assigned to them and certainly can’t work harder and faster to make it seem like they’re doing two tasks at once. In fact, equipment resources can never multi-task.

Case Study – Privately Owned Las Vegas Company

A couple of years ago I connected with a Las Vegas company that is sort of in the entertainment industry. They supply mechanical automation and control equipment to the theatrical, themed attractions, motion pictures, and touring production markets. So there were two things different for me about this type of project management consulting work….

• It wasn’t a typical IT project – in fact it really wasn’t IT at all. The PMs were not your typical PMs…they were more like project administrators or even gate keepers. Operations had accountability to the CEO for the projects. The PMs did not really ‘own’ the projects like we would think of PMs owning projects.
• It had a strange cool factor. Their equipment was used for shows I had been to on the strip, movie stunts I had watched in theatres, and theme park rides I had been on.

At any rate, it definitely forced me to change some of my thought processes as I tried to build processes around what they were trying to do project-wise and for resource management. They lacked project templates, that’s for sure, and I helped them build those by first reviewing their open projects, then understanding the project flows, and finally understanding what a ‘typical’ project usually consists of.

The Issue

The bigger issue – and the real reason they called me in – was to help them figure out how to manage their resources. The great sales guy up front was the CEO and he was good at making sales…which meant he was also good at over-committing resources. They had a great reputation of supplying a great product on time and when show and movie releases depend on it your reputation can sink fast if you don’t deliver.

This may seem simple to some of the readers here, but it was news to them. First we inventoried all of their resources – people and equipment. As you can imagine, with this type of operation most of their resources were equipment. Both the equipment for the productions and the equipment to make the equipment for the productions had to be managed – since they actually made most of their own equipment in-house.

The Solution

To do this, I utilized MS Project – as I had done for their other projects and future projects as we crammed them into the templates I had created for them. I then loaded all resources, with cost rates, codes, etc. into a separate MS Project schedule to be utilized as a shared resource pool. We then linked all current projects to this pool meaning that the projects themselves did not have resources loaded – they were tracked in the separate shared resource pool MS Project file.

It worked great and it gave the PMs, the Operations Manager, and the CEO excellent insight into where their resource commitments were today and two months down the road as they were looking to had more customers and projects.

Other Possibilities

There are other solutions and I priced doing the whole MS Project Server and MS Project Professional combination for full collaboration. They’re a profitable shop, but something like that was more than they needed at the time. And web-based tools like ProjectOffice.net can offer good, cheap collaboration among PMs and personnel, but that wasn’t on my radar at that point in time either.