The project management task you (almost) never do

The James Webb Space Telescope is the largest optical space telescope ever built. It is designed to see over 13 billion years back to the dawn of the universe. Although the functionality of the telescope meets or even exceeds expectations, the project cost more than 10 times what was originally planned and arrived 14 years late. The Webb team learned what IT has long known: the bane of project management is estimating.

Toss a coin a hundred times and half the time it will land heads and half the time it will land tails. Project estimates (effort, time and cost)? – well, that’s another story. The antidote is that project managers are more than five times more likely to underestimate effort, time, or cost than to overestimate it. Why do we so often underestimate? Well, maybe it’s in our genes. If we ignore for the moment evolutionary biology, genetics, neurosciences, neuroepigenetics, phylogeny, phrenology, not to mention the Hardy-Weinberg principle, we see how underestimation is an evolutionary advantage for our species. How many times have you said that if you knew how hard it would be to do something, you would never have done it? If Thomas Edison had known how difficult it would be to invent the light bulb, would he have tried? If the US Congress had known what the Webb Telescope would cost, would it have funded it? Underestimation is a huge advantage for our species, as it allows for the creation/discovery of things that rational minds avoid.

However, if certain evolutionary traits are an advantage for the species, they can be a disaster for the individuals of youkind of hat. For example, salmon swimming upstream to spawn is good for the salmon species, but individual fish do not survive the journey. And the praying mantis eating its mate, well, let’s not even go there. Likewise, while underestimation may be essential for the human species to progress, it can wreak havoc on the individual., as project manager.

The reality of the situation is that whatever you do, you might be destined, perhaps by some aberrant gene, to underestimate the effort required to build your system. It’s the estimation riddle. Systems development Kobayashi Maru. The dead end scenario.

There is only one practical solution for this genetic peculiarity: feedback. The project manager needs frequent, timely, and accurate feedback on the quantity and quality of all features produced, as well as the time and cost it took to produce them. (See “Planning for the Perfect,” SD time, March 2020). With constant feedback, the project manager can finally overcome his genetic destiny. The first source for understanding the scope of the actual project deliverables and their costs is the post-project review (PPR).

The project PPR is a chapter in the history of the project manager and IT. It provides the necessary feedback so that the project manager can continually learn and improve their project management skills. It can also be a valuable learning tool for other project managers, or future project managers, on what to do, what not to do, and what to avoid like the plague. .

The internet is full of free PPR templates and sample reports to download. You just have to choose one and follow it. They all look a little different, but the differences are largely irrelevant if they include a traditional mathematical look at schedules, staff efforts, costs, deliverables, etc. as well as two additional critical components. The first is lessons learned, a review of the successes and failures of the project. This section is the keystone of any hope for future project managers to learn from the experiences of those who came before them. The project manager should detail what worked, what didn’t and why. All topics are fair, including tools, techniques, personnel (user and IT), productivity, user availability, vendors, testing issues, working conditions (office space, technical resources, pizza delivery, etc.), and even those moments of genius as well as mistakes made by the project manager.

The second critical element is recommendations for future system development projects, where the project manager talks to future project managers (or their future self), detailing what future project managers should look for and what they should do differently. Think Dear Abby giving love advice, but the advice here is for future project managers.

However, this is only possible if there is a robust and truthful PPR. Many PPR tasks are included in the initial project plans, but they are eaten up by the two PPR enemies: poor project planning and scope drift. Once the project manager discovers that schedules or costs will likely exceed the plan, the hunt is on for tasks that can be sacrificed. The PPR is often the first. The PPR of 20 people a day is reduced to 10 days, then to 5 days, then completely removed in a computer sleight of hand.

There are a few critical success factors for a good PPR.

1. Group the PPR into the project plan. The best way for a project manager to increase the chances of getting a decent PPR is to bundle the review (including its timelines and costs) into the project plan. Some user managers might be reluctant to pay for a PPR. Telling a user organization that it is being charged for a task that could only benefit another user organization is often a failure. If PPR becomes an integral part of IT development methodology, it could very well pass the scrutiny of users. If this becomes an issue with user management, the project champion can be helpful in convincing the user of the value and importance of a robust PPR (See “Projects, Policy and Champions”, SD HoursMarch 2022).

If user management refuses to fund the PPR, the project manager should encourage IT to foot the bill. It might take a little selling (See “Half of Management Is Selling”, SD HoursNovember 2020) but if the project manager is focused on the IT benefits, everything could be fine. If the IT department does not have the funds to pay the PPR directly, it can consider the cost of the PPR as a project overhead item and bundle it into the IT department’s daily billing rate.

2. Positives and negatives. This is not a summer camp where each child receives a trophy. Explain what went well, but also point out what could have been done better. Do not defend what is not defensible. If IT has failed to ensure that the necessary developers or development tools are available on time, say so. If user management never delivered the promised space the team needed, say so. If the project manager miscalculated the test time, confess. (Don’t worry about retaliation. When was the last time a user or IT management voluntarily read a project team deliverable?)
3. Be honest and objective. It makes no sense to go through the effort of a PPR if it becomes a flaky morsel (just the good stuff) or thin soup (a two-page Hallmark card congratulating the team). Remember all those times you came home frustrated and kicked the dog? It’s a chance to explain those vet bills, cleanse the soul of the disappointments of being a systems developer, and help the team members on the next project improve their canine relationships.

Honesty is especially necessary to understand the productivity of a project. Accounting can give you an accurate “dollar spent” (cost) for the project, and HR the staff hours consumed (effort), which may be the only numbers senior management cares about. However, to understand productivity, these two numbers are meaningless without also considering the work done (the fully developed and tested functionality of the system). If functions have been removed or their usefulness reduced, tests have been shortened or documentation has changed, and these changes are not taken into account when calculating productivity, then a false figure will appear, the cycle poor and inaccurate feedback will continue, and any hope that project managers will learn from their experiences will evaporate. Make sure that the actual functionality provided is the basis of any PPR.

4. Include many entries and many comments from many people. The PPR is not an opportunity for the project manager to settle accounts. Each member of the team, IT and user, IT management and user management, must have the opportunity to add their comments and rants to the PPR. However, the PPR is not a social media blog. There should be an “official” notice written by the project manager. However, just as the United States Supreme Court might have a minority opinion accompanying the majority opinion, there should be an opportunity and a place in the RPP for those who disagree with the chief’s findings. project to show their opinion.

There are four important points to remember for the PPR:

1. Unless you are retiring after the current project, past projects can help you hone your skills for future projects.
2. The PPR is the best vehicle to learn from past projects.
3. Use the PPR to build an image of yourself as a project manager. (a) Where do you usually underestimate or overestimate? (b) What should you have done differently? (c) What processes, data, or personal skills would help you be a better project manager?
4. Tell the truth – lying, shading or coloring in what really happened is a waste of valuable project time.

Done correctly, post-project review can be one of the most useful and cost-effective tools in the computer systems development arsenal. Your dog will also like it.

George Tillmann is a retired programmer/analyst, project manager and CIO. This article is adapted from his book, Project Management Scholia: Recognizing and Avoiding the Biggest Project Management Mistakes (Stockbridge Press, 2019). He can be reached at [email protected].