In our domain, Jon Katzenbach's definition of a team informs how we interact with our project members. A Team is defined as ...
A group of qualified individual who hold each other mutually accountable for a shared outcome - Katzenbach, Wisdom of Teams
It has been suggested that ...
The Estimate-Commitment relationship stands in opposition to collaboration. It works against collaboration. It supports conflict, not teamwork.
This position is counter to our Katzenbach based teaming processes. The conjecture that estimates work against collaboration, rather than for collaboration, removes the mutual accountability condition for team success.
This is like speaking with our builder about the bedroom remodel project and him saying...
Oh here's my estimate to complete your bedroom remodel, but I have no intention of meeting that estimate.
Where we work, Estimates provide clarity and understanding of the mutual accountability for the shared outcome between the group of qualified individuals.
Where we work, and apply Agile software development processes, we've adopted Seven Pillars of Program Success. We work hard, every day, to: †
- Have a well understood set of capabilities needed to define "Done" in units of measure meaningful to the decision makers. These are usually stated in terms of effectiveness and performance.
- Have a genuine integrated plan associated with measuring physical percent complete in terms of Quantifiable Backup Data (QBD) to inform our Estimate To Complete (ETC) and Estimate at Completion (EAC). This QBD is a perfect fit with Agile's working software, predefined with the needed capabilities. This is why, in our domain, Earned Value Management + Agile is a match made in heaven.
- Produce an independent estimate of the cost, schedule, and probability the needed capabilities will perform as planned. These estimates is truly independent and not part of a missionary movement where people are trying to sell the program or force it to fit within the available funds.
- Provide sufficient and stable funding.
- Establish a culture of asking for and listening to outside competencies.
- Assure a willingness to ask hard questions and the courage and energy to not quit until there are credible answers to the questions.
- Recognize that it takes requirements (the implementation of the capabilities), resources, business processes, and everyone working together to increase the probability of success.
Your domain of course will be different. You or your team may not work on projects must succeed on our before the needed date, at or below the needed budget with the needed capabilities. That is, you can show up late, over budget, and with missing capabilities and the customer will consider that OK. And just to be clear, the notion of the value of incremental delivery is defined by the receiver of those capabilities, not the producer. Ask the customer if the partial outcomes can actually be put to productive use in the business environment. Capabilities Based Planning defines which capabilities are needed in what order to provide business value.
We show up late, over budget, and with missing capabilities many times of course - so no need to point that out - without corrective actions attached. Any number of reports, including bogus reports show this. But a critical understanding is we know we're going to be late, and we know we're going to be over budget, and most of the time we know the delivered capabilities will not meet the intended specifications every reporting period and have a plan (maybe not the right plan) to fix it.
Risk Management is How Adults Manage Projects - Tim Lister
In our domain, being late, over budget, and less than required capabilities it is never acceptable to the customer. Are we late, over budget, and have performance issues? Of course. It's called development. But we know it, have visibility to the root causes, and have corrective action plans. This visibility is part of the process. Without a steering target and actuals, no error signal can be generated to be used for course correction. One of our PMs was a Navy navigator on an air craft carrier. The commanded heading was required for him to carry out is navigation processes. Without estimates of the impediments to be encountered along the way for the course to the desired destination, the productivity of progress, with effort to make progress along the course there is no way to know which path to take to that destination. By the way, measuring past performance and projecting that as future performance only works if the future conditions are like the past conditions. This is rarely the case on any sufficiently complex project.
Yogi Berra reminds us — If you don't know where you are going, you'll end up someplace else.
This poor performance is actually reported in a database for review every reporting period (minimal monthly) and used to adjust award fees and assessment for the next job that significantly impacts the selection process. This is called Closed Loop Control.
When there are no Estimates to Complete (ETC) or Estimates At Completion (EAC) there is an Open Loop Control condition and the corrective actions needed (but not always effective) have no steering target with variance to steer toward to move the project back to GREEN.
So estimates don't stand in the way of cooperation, they are the foundation of mutual accountability for the shared outcome based on cooperation.
† These seven pillars are derived from VADM Joseph Wendell Dyer, USN (Retired), Navy's chief test pilot, F/A-18E/F Program Manager, and Commander, Naval Air Systems Command, plus ten years as an executive at iRobot Corporation. Many of our projects are not VADM Dyer's but they are still mission critical, manifestly important to the success of our customers business success. If they were to fail - cost too much, show up beyond the business need date, or not provide the needed capabilities, the success of the business is in jeopardy. Again you're domain my be significantly different. Use as appropriate.
