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.