Part 2: Project Controls “Controlling the Chaos”
This Project Controls “Controlling the Chaos” blog series is a continuation of our blog, Project Control or Project Chaos: You Decide.
I'm not here to teach you how to schedule, but rather who to apply throat hugs to as you try to manage and control your own projects. We all know that external vendors can be trying at times. It’s crucial that we understand how to analyze their “schedules”, so we can get real data out of them as we try to manage and maintain our master schedule.
Project Controls - First Things First
We need to lay out some groundwork and common definitions to be able to move forward. Without this, the rest of what I will say may be foreign to you.
- Project management is not a contact sport – leave the “padding” at home – ALWAYS!
- By definition, padding a schedule is adding some amount of 'additional' time/money to part or all of a schedule, in excess of the expected duration/cost, that allows…the published schedule to be met.
- Blind “padding” a schedule by default is a "bad practice". Any type of “contingency” should be done thru a regular and thorough risk analysis process. Once you work through your risks, you have a quantifiable and qualified list of reasons to add more time/money to a particular task.
- Bad schedules are the PM's fault – ALWAYS!
- If you as the PM turn your team loose on a project based strictly on the client’s/customer’s/sponsor’s schedule, you have doomed your team to failure.
- Desired dates and “Enterprise Environmental Factors” should always be considering when building a schedule – but – your schedule creation should be based in reality with your teams’ input. First, you and your team must analyze the tasks leading to the potential end date and remove all barriers within you and your team’s power to meet the customer’s deadline. Then, you must go back to your customer with “My team and I have analyzed the work involved and believe we can hit [new date your team agrees to] without issue. However, to get to the date you want, we will need X (X being more resources, additional budget for overtime to meet the desired date by the customer, etc.).
- By doing the above, you build credibility with your team that you’re not just throwing a date at them which inevitably will require 60 hours a week. On the flip-side, you build trust with your customer by letting them know upfront that you understand the request and work required to meet their desired result.
- WBS (Work Breakdown Structure) for every project – ALWAYS!
- The absolute best way to show your customers and stakeholders not only issues with desired or hard dates but also as an ongoing reporting tool is to share your WBS layout with them. This shows the client that not only do you understand the work that needs to be done but how it is organized to obtain the desired results. A solid WBS will help to clearly define the scope so that nothing slips through the cracks during actual execution of the project.
- When creating a WBS, you continue to break out large buckets or deliverables into logical, smaller buckets or deliverables, You continue to breakdown deliverables until at the bottom level , you can easily estimate, control and report on these items easily.
- REMEMBER – as you are breaking down these buckets/deliverables, there is no “action” with them. These will all be nouns, not verbs.
- Tasks/activities (under work packages) will be where you add verbs with a noun. “Purchase x” or “Install y” would be examples.