Promises and Prescriptions
February 17th, 2004 by HalFrank Patrick is at it again. His series Promises and Prescriptions that started Feb 15th is worth reading a few times over. Frank starts with the statement,
Projects — including software projects — are about promises.
For some reason this needs to be said over and over again. We routinely involve people in our project without telling them what has been promised to a customer. Then we wonder why they do things that are inconsistent with the promise!
Projects are about turning uncertain work efforts into reasonably certain outcomes.
The collected outcomes represent the set of conditions for satisfying the customer. We want to be very clear about those conditions with the customer. And we need to stay in conversation with the customer about that set of outcomes to adjust as the team innovates, learns, along with the customer.
Project sponsors, customers, and stakeholders rely on project promises to carry out and coordinate larger strategies in support of organizational needs.
While we know that others rely on our promises, we often don't find out why the promise matters. The "why" serves as the context for the project. Knowing the "why" allows the team to innovate rather than just do what had been decided by others sometime in the past. The "why" offers team members freedom to be their creative selves.
Yet, making and keeping those promises are hindered by common problems: people on projects are reluctant to promise the unknown, plans are disrupted by rework, and schedules are thwarted by contention for resources that are involved with more than one effort.
Eventually we get to the point where each project performer has to make commitments. It's the only way projects are completed. As Frank says, people are reluctant to do so in the face of uncertainty.
It looks like Frank has organized the balance of the series around three common complaints: rework, resource contentions, and fear of promising the unknown. Frank made three postings so far including a sidebar Why Projects Are Hard. I'll offer my comments on that tomorrow. In the meantime get over to Frank's Focused Performance Business Blog. While you're their subscribe by email or add his RSS feed to your feedreader. If you care about projects, then you want to be reading Focussed Performance.
Related Posts
- Why Projects are Hard This sidebar to Frank Patrick's series on Promises and Prescriptions attempts to show why it is we find projects hard. ...
- Shield Performers when Work Is Not Ready Promises and Prescriptions Part 5 - Set a Priority to Eliminate Multi-Tasking I agree with Frank Patrick whole-hearted...
- The Added Work of Rework Promises and Prescriptions Part 2 - The Added Work of Rework, by Frank Patrick "There's never time to do it right,...
- Update to Securing Reliable Promises on Projects Securing Reliable Promises on Projects Back in July 2001 I wrote this paper on promising that I later made available...
- Address the Project Team’s Mood then the Impossible Deadlines Here's another piece on deadlines. You'll remember Aubrey Daniels said look to the system when deadlines are missed. T...
February 17th, 2004 at 7:48 pm
I would like to comment about the first complaint: Rework
I see rework as a work that is required to reshape the interdependence of sub activities that are related to a process or project in a way to keep the flow continuous.
I know that we can have rework as a result of a lack of knowledge or mistakes but most of the time they are result of the uncertainty of the process that we are managing and we must not see them as a problem.
Projects without reworks are not flowing.
I would be very glad if you could share your point of view!