Project Management

Project or Program Success: What Matters

From the Project or Program Success: What Matters Blog
This is about setting up the element for project success. Thinking about leadership and courage that needs to be executed when you are faced with challenging projects or programs.

About this Blog


Recent Posts

Modelling for Success

The Problems ITIL Solve

Shutting A PMO Down

Project or Program Success: What Matters

Reasons for Replacing An ITSM Tool

I have been a practitioner of project management for a while.  I was attracted to it because of the opportunity to work with smart and intelligent people that creates a product and delivers value to the organization.  Often times, I would encounter organizations whose perspective of project management is simply having a list of tasks that need to be done by a mandated timeline.  I have questioned this work model in every conversation I will have with folks.  I thought is this project management or simply just being a task master.  I believe it does not take a lot to be a task master specially when you use the power of coercion to get a job done.

I have tried my best in my practice to start any project I am involve with identifying the scope of work that makes up the product and estimating time.  Often times, I will get an order that says I need this project done by a specific date.  I would ask my stakeholder what is the business driver for this.  I will ask who is our sponsor so that we can manage the work and manage expectations properly specially when the driving constraint is schedule.  Many a times, I would see projects executing as soon as the executives said get this job done by this time.  I still have to meet an executive who will stay rational when push comes to shove.  Projects driven by this kind of pressure usually under perform.  It is a hidden cost to the project that is not highlighted.  No ones pays attention to the process of estimating work to manage and mitigate schedule risks.  Most of the time you will see a PM under pressure who would start building a project schedule by himself with no or little project analysis and definition. 

What do we normally do when we miss a "promised" delivery period?  I would assume many can come up with various reasons in and out of the project team's circle.  I probably would say start with a strong leadership and a determined goal of improving the culture of "just do it".  Project stakeholders and sponsors should be made aware and hopefully get them to emphasize the value of accurate estimates.  Our estimates should improve one project after the other and management/leadership should reward such improvements.

One thing that I have promoted is the PM fundamental of creating a work breakdown structure (WBS).  I don't see any project team that does this work anymore.  However, this is one of the ways we can improve our estimates; by creating a WBS.  The WBS helps visualize work packages or backlogs that will make up the product the project should deliver that gives value to the business and meets the customer needs.  The WBS enables us to define work better and properly I hope.

What should be the next step in the cycle when you choose to practice the creation of WBS in your projects.  I think you need to have the project team members involve in identifying the work package items and let them provide the estimates.  This is a another fundamental PM practice.  The project team members knows their availability and the work that needs to be done.  Therefore they are in the best position to provide an accurate estimate and a not guestimate if it is only one person creating that project schedule and putting estimates himself.  Estimates are estimates and should be treated as such.  Project managers and executives should be honest to the stakeholders when the estimates have to change.  Again this is in the interest of managing expectation and mitigating project conflicts. 

You have heard how the agile techniques have help projects deliver faster.  I say this is not different in project estimating.  BTW, you need to have a method for estimating.  In agile, they use planning poker.  I would again go back to another PM fundamental in estimating which is the 3-point estimating technique in case you don't have a way to use analogous estimating method.

More importantly, always account for schedule risks specially those driven by the unknown unknowns.  You need to create contingencies both in your schedule and budget.  This is also your opportunity to validate assumptions to help you better understand project risks.

BTW, have a method of tracking effort and progress.  Your team will be loaded with work that would distract them from doing project work.  It is important that you have a mechanism to identify potential timeline issues before the schedule gets impacted.  I use the earned schedule method on plan-driven projects.  In agile methods, I use the backlog, release and sprint planning to understand project performance through either the burn up or down charts.

In the end, you need to have a method of ensuring that you can meet the schedule goal at the minimum and deliver value as early as possible to the business.

Posted on: March 10, 2017 05:16 PM | Permalink

Comments (3)

Please login or join to subscribe to this item
Cool write up Randy. Thanks for sharing your thoughts.


Please Login/Register to leave a comment.


"When I have a kid, I wanna put him in one of those strollers for twins, then run around the mall looking frantic."

- Steven Wright