Making Good Project Decisions

Decision-making is an ongoing task on every project engagement.  Key decisions have to be made throughout by everyone including the project manager, the project team members, the customer, executive management, and usually other stakeholders.  They may be as simple as when to hold a meeting or as difficult as making a go- no-go decision on a phase of the project or the entire project.

What we often lack when making some key decisions is the right information at the right time.  We all know that making what seems to be the right decision based on information that ends up being inaccurate or out of date can be fatal to the project.

What if you could only make decisions on when to cross the street based on a snapshot taken five minutes ago?  Would this help?  Would you have any confidence in whether or not you should cross the street?  After all, it could be a life or death decision.

Well, that’s often how organizations are continually making business and technology decisions.  Many decisions we make on projects are based on what we knew two days ago or two weeks ago or what someone told us last Thursday.  Ideally, information would be flowing to all key personnel constantly and we would be making key business, project, and technology decisions based on what we just learned – not what we knew last week.  What if you could make sense of what you learn as fast as you learn it and put that into play?

There is no magic wand to wave to make this all happen.  However, since the project manager is the key focal point for all communication on the project, there are some things – or at least some actions – that can be put into place that will help ensure that the right information is getting to the right people as quickly as possible.  And that, in turn, should help ensure that the project decisions that are made are based on the most relevant and accurate information possible.

These are:

Develop and distribute a communication plan

The key to getting all of this communication off on the right foot is to publish a communication plan for the project at the outset.  Produce this document shortly after kickoff and let it document and set the tone for all communication that will flow on the project.  This document will correctly set expectations of how, when, where and through who communication will happen. For more information on the project communication plan, please read an earlier article of mine on the topic here.  You can also download a copy of one of my actual project communication plans to use as a template.  Go to www.bradegeland.com and navigate to the Templates & Downloads page to access the sample plan.

Read more »

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…