Project Management Excellence – A Path to Success

Project Management can at times feel like an exercise in the tedium.  A pursuit of an end goal with a trail of bread crumbs that seem to never end. Over the years I have come to respect the profession even more as it has expanded and evolved to try and address every type of scenario that one can dream up from a product development, execution and delivery perspective.  Of course, this has led to some successes and some challenges as teams try to stay abreast of the latest theoretical constructs for all things project management related.  Knowing when to test out a new idea under the charge of continuous improvement versus the cut to the chase approach that some mavericks prefer, can prove to be a daunting exercise in advancing the practice at the expense of advancing the project.   Sometimes we can get too caught up in learning about a new shiny widget that we lose perspective on the tasks at hand.  In this article I will address some focus areas to keep top of mind as you plan for the next project.

 

The Business Case is Everything – The answer to why this project is important, the success criteria and even the ROI is important to ensuring that execution is aligned in a manner that promotes success and value for the organization.  Always question the timelines and perform the appropriate due diligence to arrive at the best timeline for delivery.  Inform stakeholders that timelines are tentative until requirements are fully understood.  If a Project Manager is not clear on the business case they should immediately draft a charter of the project to help connect the dots.   While charters are non-existent or have dwindled down to a 1 pager in deference to Agile principles, they can still serve as a vital tool in helping Project Managers organize thoughts around how to plan and manage the project.

 

Ban Heroics Entirely – There is a tendency to work towards meeting the end date only to find that as the date begins to slip a monumental effort of heroics, brainstorming and strategies emerge to try to accelerate task and milestone completion. We have to stop waiting for those extinct level events before we adopt an expedited delivery approach that says we will beat the target date with a rapid delivery mindset from the very beginning of the project.

 

Rapid Start – Kickoff the project right away.   Don’t wait until you have all the answers.   A Rapid Start is an accelerated kickoff meeting with all stakeholders.  Share a roadmap and high-level vision for what the project is all about and discuss the need for resource commitments to help execute the project.  Communicate the basics on what methodology will be followed, key roles, how requirements will be managed and what Subject Matter Expertise (SME) will be required to drive results.

 

Methodology – Be careful in this area because it can get you in trouble very quickly. It doesn’t matter if that new Project Manager is fluent in the latest methodology if it has not been rolled out to and understood by the other stakeholders.   There are pros and cons to varying approaches so make sure that the organization is in a ready state to embrace new techniques and approaches to delivery including changes to culture and behaviors that will help drive success.  The ‘toe in the water’ approach may not be appropriate for critical or high-profile projects.  Consider piloting new processes, tools and approaches on lower risk efforts first and then scale accordingly.

 

It’s Not the Plan, It’s the Planning – Producing a plan that no one reviews or is not leveraged in weekly delivery team meetings is a missed opportunity to use a vital tool. As a Project Manager, ask the big questions to better understand what you really have at your disposal to make this project successful.  Here are some key areas of focus:

 

  1. Does the estimated duration make sense? If not, call that out upfront and insist on contingency from the leadership team.
  2. How reliable is the vendor based on prior experience and what internal resources are required for delivery? Make sure the vendor understands your delivery approach and leverage synergies I that space.
  3. Do we have test environment availability to support testing and what type of testing is required? Consider risk-based testing where it makes sense.
  4. Draft your first cut project plan from scratch. Don’t use templates upfront.  Think through each step and connect deliverables to the success criteria identified previously.
  5. Project plans that only have phases and do not include success criteria minimizes the opportunity to gain stakeholder satisfaction. Business stakeholders on a technology project will not understand how you completed the tasks for a particular phase but success criteria were not delivered. Include it in the plan.

Requirements and Analysis – “Perfect is the enemy of good” – Voltaire.  Major disconnects here are not always about an itemized list of things that stakeholders want.  In fact, I would submit that breakdowns in the delivery of requirements and the proper analysis that comes with them is related to building relationships.   Eliciting, documenting and analyzing requirements is an iterative and constantly evolving process.  Too much time is spent on drafting and not enough time on understanding and level setting.   Yes, level setting is important.  Make sure the team is engaging stakeholders on developing the requirements management plan.  Make sure that stakeholders are versed on the criticality of the requirements management process and the need for involvement every step of the way.  Rank requirements in terms of importance and have real discussions with stakeholders on the possibility or likelihood that some items may be descoped or addressed in subsequent releases.  Have those discussions early and often.

 

Coding and Development – This area always proves challenging from a process perspective.   Especially with the proliferation and move to SaaS products and services.  PMs typically follow for status and verification of delivery and leave developers to own and run their space.  Probably not a bad idea since they do speak and write different languages – pun intended.  However, that doesn’t mean that there are no opportunities to influence the quality of solution delivery in this space.   PMs should seek to understand the development/configuration approach and processes.  Ask the development/configuration team for their Software Configuration Management (SCM) Plan. Ask them to share the build notes and evidence code/config walkthrough sessions. It doesn’t matter if the work is internal or external it is critical to ensure that code/configurations are properly controlled and introduced into the environment in a systematic, secure and repeatable manner.   PMs have these questions early and upfront with the technical team.

 

Test Management (QA/UAT) – As a PM always ensure that you ask the right questions around test management planning.  Traceability is important but the approach to testing and the verification of adequate coverage is just as important.  Make sure that test cases/user stories record actual results.  Ensure that the team can demonstrate sufficiency of testing and that testing templates have been updated, defects properly recorded and remediate to a degree of satisfaction including requisite approvals.  Adopt a better practice by having the BA and testing team come together for walkthroughs and peer reviews and invite SMEs from other areas in support of greater transparency.     

 

Deployment – Almost there but this is the silent deliverable that can cause significant challenges.  I recently worked with one of the big 4 accounting firms on a risk management application that was mission critical to the organization.  Deployment of the updates failed twice before I was assigned to the project resulting in a rollback to the previous version.  At one point it seemed like they were better at rolling back applications rather than deploying them. The solution to rightsizing this effort included the development of a set of tools to help align all stakeholders around critical delivery, establishment of defined smoke testing processes and the most important of all – a rededicated effort to capture and share knowledge about the application specs, usage and behaviors.  We also established a Change Advisory Board which was not in place at the time to help implement a system of controls to ensure applications and significant changes were ready to be published.              

 

The Vendor Will Cover It – Famous last words. Vendors are partners but one should not presume that they don’t need to be closely managed and monitored for results.   Make sure that vendor understands your processes and have them reference your Project Delivery Lifecycle in the SOW.   Make it clear that they are expected to deliver in accordance with your process standards at every stage.  In cases where the vendor may be the only game in town, hold some entry criteria discussion to better understand how their processes align to ours and managed gaps where there may be significant risks.

 

Project Management Tools – There are a number of tools in our profession that can certainly help support delivery and execution.  Beware of the tool advocate that resists all other tools.   People tend to want to work with what they are familiar with and it can turn into a this versus that argument over what works best.   Tools enable process but they are not the process and that is an important takeaway from this article.  It doesn’t matter how good your PPM tool is if PMs are spending 50% of their time inputting data and not working to drive projects.  You just may end up with a bunch of great reports that tell you that you’re failing.

 

I trust that you will find some of these points relevant as you prepare for the next project that lands on your desk.   This is a challenging profession and it requires an adaptive mindset but I promise that amid some of the challenges along the way, you will encounter opportunities to greatly influence and contribute to the strategic value of the organization. Try not to get lost in theory and conjecture and when in doubt, trust your common sense.


Gary Garris

Gary Garris is a business and technology professional with over twenty years of experience helping organization drive transformational change. Working for global companies like Moody's, Prudential Financial, AIG, Ernst & Young, AICPA and MetLife has led to a well-rounded career with significant accomplishments in the areas of product development, process engineering, risk management and application development. Gary is an author, a Six Sigma Black Belt & Lean Certified as well as a Certified Scrum Master. Please contact Gary with questions/opportunities/assistance at [email protected]