Controlling a project

Controlling a project is doing something about what the progress report shows: “Controls are actions taken as a result of reports” [1]. It decides which variance gets action, which action, and when a project should stop.

1. Set the threshold before the number arrives

A line agreed at the start stops “we’ll catch up next period” from winning. A magnitude line catches a large gap: Wysocki treats a 10% cost variance as “the most allowed” [1], and a construction convention puts Green under 3% impact on schedule or cost, Yellow at 3–5% and Red above 5% [2]. A trend line, such as a milestone slipping report after report, fires earlier, and early matters: cumulative CPI settles by about 20% complete [3].

Crossing a line starts an analysis, not an action: “the conditions must be analyzed to identify why the variance exists” [4]. A slow team and a growing scope draw the same late number and need opposite responses.

2. Every corrective action spends something

Overtime lifts productivity, but lowers quality; the rework flows back into effort, schedule and cost, and the project is behind again Overtime is the lever.

Overtime gives a short gain, then “an aggressive decline in velocity along with a simultaneous decline in quality” [5], and the rework flows back into schedule and cost. Overtime buys a week now and rework later. Adding people has the same shape: “Adding manpower to a late software project makes it later” [6].

Wysocki orders the alternatives by who pays, cheapest first [1]:

  1. Leave the slip alone if the task has float.
  2. Overlap tasks planned end to end.
  3. Reassign people from non-critical work.
  4. Ask resource managers for more.
  5. Offer the customer the key features on the date, the rest later.
  6. Ask for more time, which “offers the customer nothing in trade.”

For example, a word processor’s export module is a week behind on the critical path; the spell-checker is behind too, but has float, so it is left alone. The team overlaps export’s file-format and UI work, borrows a spell-checker developer, and if that fails ships two export formats on the date. Nobody works weekends.

3. Predictive and agile control steer different things

Both run a feedback loop, but they let different variables move.

  Predictive control Agile control
Held fixed scope, the baseline the time box: date, budget, team
Steered cost and schedule, back to the baseline scope, by reordering the backlog
Where variance review, weekly or monthly sprint review; daily scrum

On one newspaper site the release burndown sat far above ideal; the company simulated cuts and “successfully launched a reduced release after 9 Sprints” [7]. Before acting on a stalled burndown, ask whether the team slowed or the target moved.

4. Stopping a failing project

Here escalation means raising a problem to someone who can fix it; Wysocki’s six steps are the escalation ladder, and escalation of commitment, never shortened, is continuing a failing course despite negative information [8], [9].

CONFIG, a sales-configuration expert system, was funded for more than a decade while its usage fell from about 2.3% of quotations to about 0.1% [9]. One manager wrote three whistle-blowing memos; a sales rep said “The problem is nobody is willing to kill it.” It ended when its champion died: nobody had written down what failure looked like.

A stop rule is a threshold on what the project is for, set before anyone is attached. Keil’s outsider question: “If I took over this job for the first time today and found this project going on, would I support it or get rid of it?” Escalate the problem early, so nobody escalates the commitment later.

5. When measurement bites back

A number used to judge a team moves toward its target. Bouwers et al. name four failures: a metric without context, changes made only to move a metric, one metric alone, and too many to read [10]; see Process metrics and Velocity and flow. DeMarco grants his “You can’t control what you can’t measure” a “real truth”, but “strict control is something that matters a lot on relatively useless projects and much less on useful projects” [11].

6. When to use it, and when not

Set thresholds and a stop rule at the start of any project with a budget or a committed date, tightest where the value margin is thin. Where it is wide, keep control light.

How solid is this?

  • Where it comes from. Thresholds are rules of thumb from a textbook, space flight and construction; none shows that its value is right.
  • What is contested. Brooks calls his law “Oversimplifying outrageously”. The loop is lecture material; its signs are our reading.
  • What we do not hold. Evidence that thresholds, the ladder or stop rules improve outcomes. Stopping rests on one case.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [12], [13] on software project management, including the control loop.

References

  1. R. K. Wysocki and R. McGary,
    Effective Project Management: Traditional, Adaptive, Extreme, 3rd ed. Wiley Publishing, 2003.
  2. A. P. Snow and M. Keil,
    “The Challenge of Accurate Software Project Status Reporting: A Two-Stage Model Incorporating Status Errors and Reporting Bias,” IEEE Transactions on Engineering Management, vol. 49, no. 4, pp. 491–504, 2002, doi: 10.1109/TEM.2002.807290.
  3. D. S. Christensen,
    “The Costs and Benefits of the Earned Value Management Process,” Journal of Parametrics, vol. 18, no. 2, pp. 1–16, 1998, doi: 10.1080/10157891.1998.10462568.
  4. NASA,
    “NASA Systems Engineering Handbook,” National Aeronautics and Space Administration, NASA Special Publication SP-2007-6105 Rev1, Dec. 2007. [Online]. Available: https://www.nasa.gov/reference/systems-engineering-handbook/
  5. K. S. Rubin,
    Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley, 2012.
  6. F. P. Brooks,
    The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc., 1995.
  7. V. Mahnič and N. Žabkar,
    “Measuring Progress of Scrum-based Software Projects,” Elektronika ir Elektrotechnika, vol. 18, no. 8, pp. 73–76, 2012, doi: 10.5755/j01.eee.18.8.2630.
  8. M. Keil, H. J. Smith, S. Pawlowski, and L. Jin,
    “‘Why Didn’t Somebody Tell Me?’: Climate, Information Asymmetry, and Bad News about Troubled Projects,” ACM SIGMIS Database: the DATABASE for Advances in Information Systems, vol. 35, no. 2, pp. 65–84, 2004, doi: 10.1145/1007965.1007971.
  9. M. Keil,
    “Pulling the Plug: Software Project Management and the Problem of Project Escalation,” MIS Quarterly, vol. 19, no. 4, pp. 421–447, 1995, doi: 10.2307/249627.
  10. E. Bouwers, J. Visser, and A. van Deursen,
    “Getting What You Measure,” Communications of the ACM, vol. 55, no. 7, pp. 54–59, 2012, doi: 10.1145/2209249.2209266.
  11. T. DeMarco,
    “Software Engineering: An Idea Whose Time Has Come and Gone?,” IEEE Software, vol. 26, no. 4, pp. 95–96, 2009, doi: 10.1109/MS.2009.101.
  12. E. Miranda,
    “Managing Software Development.” 2014.
  13. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.