Milestones and Deliveries
by Rick Brenner
Pressed repeatedly for "status" reports, you might guess that they don't want status — they want progress. Things can get so nutty that responding to the status requests gets in the way of doing the job. How does this happen and what can you do about it? Here's Part III of a set of tactics and strategies for dealing with pressure.
Pressure often comes from the disparity between expectations and reality. We can limit this disparity by limiting the perceived ups and downs that come with most projects. Here are some tactics for managing pressure by smoothing out the ups and downs. See "Managing Pressure: Communications and Expectations," Point Lookout for December 13, 2006, and "Managing Pressure: The Unexpected," Point Lookout for December 20, 2006, for more.
In 1763, while Deputy Postmaster General, Benjamin Franklin measured distances from Boston along the Boston Post Road. Workers following him erected milestones at each mile point. Pictured is is an earlier milestone in Cambridge, Massachusetts.
Photo courtesy Wikipedia.org
- Space milestones evenly
- It's common practice to divide project timelines into uneven segments distinguished by milestones, with some milestones identified as "major." This practice can undermine perceptions of progress, because people prefer steady forward progress to an uneven stream of equal-sized steps forward. This is true even if the achievements vary greatly in significance.
- Spacing milestones unevenly creates progress perception problems. To manage perceptions, let go of the distinction between kinds of milestones. Have more milestones, and space them fairly evenly.
Spacing milestones unevenly
creates progress perception
problems. Have more
milestones, and space
them fairly evenly.
- Milestones near deliveries are critical
- Gaps between milestones just prior to a delivery are especially costly, because they engender anxiety about a lack of real evidence that the project is healthy. Anxiety increases if preparations are underway for receiving the delivery.
- Idle time creates fear. Choose milestones that provide news during parts of the schedule when people might be susceptible to fear.
- Deliver usable capability at regular intervals
- Even when a schedule has evenly spaced milestones, customers, sponsors, and management can become anxious when the project delivers usable capability at irregular intervals. Milestones that don't "matter" to the customer have little positive impact on perceptions of progress.
- The psychological reason for this may be related to airline passengers' aversion to itineraries that have legs in them that go the "wrong way" even when those itineraries are faster. Milestones that don't "matter" represent cost and schedule without real progress. Schedule regular milestones that have customer impact.
- Help the customer with the post-delivery environment
- Difficulties in incorporating the deliverables into ongoing operations can affect the customer's perception of the quality of the deliverables. And anxiety about the coming chaos is often reflected in perceptions of progress. Even deliverables that are 100% compliant with requirements will take the blame for internal difficulties in incorporating them organizationally.
- Do whatever you can to make incorporation easy. Automate any required conversions and prepare for transition training and help. These efforts are most effective if they're in the plan from the beginning, but add them later if necessary.
As a sponsor or a senior manager, you're uniquely positioned to smooth out the experience of these ups and downs. Establish review processes that ensure that these pressure-management strategies are used throughout the organization. Project plans should have evenly spaced, frequent milestones that deliver real value early and often. And establish after-action reviews for projects that recently passed through crises to enable project team learning.
A little pressure does help, but most of us are under way more pressure than is helpful. And we can do something about that. Top Next Issue
Micromanagement is a common source of pressure. For insights on micromanagers and micromanaging, see "When Your Boss Is a Micromanager," Point Lookout for December 5, 2001; "There Are No Micromanagers," Point Lookout for January 7, 2004; "Are You Micromanaging Yourself?," Point Lookout for November 24, 2004; and "How to Tell If You Work for a Nanomanager," Point Lookout for March 7, 2007.
Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!
Your comments are welcome
Would you like to see your comments posted here? Send me your comments by email
, or by Web form
About Point Lookout
Thank you for reading this article. I hope you enjoyed it and found it useful,
and that you'll consider recommending it to a friend
Point Lookout is a free weekly email newsletter. Browse the archive
of past issues. Subscribe for free.
Support Point Lookout by joining the Friends of Point Lookout,
as an individual or as an organization.
Do you face a complex interpersonal situation? Send it in,
anonymously if you like, and I'll give you my two cents.
More articles on Workplace Politics
- Stonewalling: Part I
- Stonewalling is a tactic of obstruction used by those who wish to stall the forward progress of some effort. Whether the effort is a rival project, an investigation, or just the work of a colleague, the stonewaller hopes to gain advantage. What can you do about stonewalling?
- On the Appearance of Impropriety
- Avoiding the appearance of impropriety is a frequent basis of business decisions. What does this mean, what are the consequences of such avoiding, and when is it an appropriate choice?
- Mitigating Risk Resistance Risk
- Project managers are responsible for managing risks, but they're often stymied by insufficient resources. Here's a proposal for making risk management more effective at an organizational scale.
- The Deck Chairs of the Titanic: Obvious Waste
- Among the most futile and irrelevant actions ever taken in crisis is rearranging the deck chairs of the Titanic, which, of course, never actually happened. But in the workplace, we engage in activities just as futile and irrelevant, often outside our awareness. Recognition is the first step to prevention.
- Managing Non-Content Risks: Part I
- When project teams and their sponsors manage risk, they usually focus on those risks most closely associated with the tasks — content risks. Meanwhile, other risks — non-content risks — get less attention. Among these are risks related to the processes and politics by which the organization gets things done.
See also Workplace Politics, Conflict Management and Managing Your Boss for more related articles.
I offer email and telephone coaching at both corporate and individual rates.
Contact me for details at rbrenner@ChacoCanyon.com
or (617) 491-6289, or toll-free in the continental US at (866) 378-5470.
Get the ebook!
Past issues of Point Lookout
are available in six ebooks:
Reprinting this article
Are you a writer, editor or publisher on deadline?
Are you looking for an article that will get people talking and get compliments flying your way? You can have 500 words in your inbox in one hour. License any article from this Web site. More info
- The Race to the South Pole: Ten Lessons for Project Managers
- On 14 December 1911, four men led by Roald Amundsen reached the South Pole. Thirty-five days later, Robert F. Scott and four others followed. Amundsen had won the race to the pole. Amundsen's party returned to base on 26 January 1912. Scott's party perished. As historical drama, why this happened is interesting enough, but to project managers, the story is fascinating. Lessons abound. Read more about this program. Here's an upcoming date for this program:
- The Race to the South Pole: The Power of Agile Development
- On 14 December 1911, four men led by Roald Amundsen reached the South Pole. Thirty-five days later, Robert F. Scott and four others followed. Amundsen had won the race to the pole. Amundsen's party returned to base on 26 January 1912. Scott's party perished. As historical drama, why this happened is interesting enough. Lessons abound. Among the more important lessons are those that demonstrate the power of the agile approach to project management and product development. Read more about this program. Here's an upcoming date for this program: