Do a Project Postmortem

At the end of every project, give all the key project members a three or four day assignment to analyze every problem that occurred during the project. For example, "We were ten days late starting integration testing. We should have told the customer." Or, "We started designing and coding before the requirements were complete." Or, "the team was already exhausted from working long hours when the CEO demotivated everyone by announcing there would be 'no raises'."

In general, the idea is to document, analyze, and learn from all the things that went wrong. Also, record what you believe could be done differently in the future to prevent it. Future projects will be improved by these project postmortems. If possible new or promoted employees should attend one or more project postmortems before becoming key members of a project.

Those who do not remember the past are condemned to relive it.

 - George Santayana, 1908

Manage by Variance

 

It is difficult, if not impossible, to manage a project without a detailed plan. Once you have a plan, update it as necessary. Now that you have an up-to-date plan, your responsibility is to manage the project according to that plan. As you report your progress, report only the discrepancies between the plan and the actuals. While the project is underway, a progress report should be, "Everything is as stated in the plan except ...." This way attention and resources can be applied to the problem areas.

Miraculous Productivity Increases

The technology industry is saturated with people who preach that this tool or that technique will reduce development cost. We all hear at business meetings and conferences about software managers claiming huge increases of 50 to 100 percent in productivity by applying tool x or language y or method z. Don't believe it! It is hype. Moderate increases in productivity of 3 to 5 percent are much more reasonable targets.

You should be happy with tools, languages, and methods that shave a few percentages off your cost or add a few percentages to your quality. However, cost reduction makes no sense without an understanding of its impact on customer and employee satisfaction. If you want to really move the needle then focus on your customers and employees.

I've blatantly used AnalyticsInHR's image because it so well addresses my point. I don't know anything about their business but it appears that they know somethings about business performance.

References:

DeMarco, T. and Lister, T., Peopleware, New York: Dorset House, 1987.

Chappell, B., 4-Day Workweek Boosted Workers' Productivity By 40%, Microsoft Japan Says, NPR, Nov 4, 2019.

The Method Won't Save You

We have all heard the preaching of "method zealots" who say, "If you just adopt my method, most of your problems will disappear." Although many methods have been the subject of such ravings, the majority during the 1970s and early 1980s contained the word "structured" in their names. Those during the late 1980s through the early 2000s contained "object" in their names. And the methods from the mid-2000s to today contain the word "agile" in their names. Although each of these waves bring great insights, as well as quality-instilling software development constructs and steps, they are not panaceas. Organizations that are really good at developing quality software are good regardless if they use a structured, object-oriented, or agile methodology. Organizations with poor records will still have poor records after adopting the latest fad method.

As a manager, beware the false soothsayers who will promise great increases in either quality or productivity based on a new method. There is nothing wrong with adopting a new method, but if the organization has had productivity or quality issues in the past, try to uncover the source of that failure before you jump to a solution. It is highly unlikely that your method is to blame!

Reference:

Loy, P., "The Method Won't Save You (But It Can Help)," ACM Software Engineering Notes, January 1993.

Community Adoption of New Practices

Community adoption of new practices can mean a lot of things.  From getting a small team to try a new methodology or tool to convincing the world that a product or service is needed.

In 1996, Robert Metcalfe was awarded the IEEE Medal of Honor for "exemplary and sustained leadership in the development, standardization, and commercialization of Ethernet." The story of how Ethernet came to be follows the 8 steps of essential practices below. I've added headings for what departments typically handles each practice in a large company. You don't have to have different people or departments. I find it helpful to get into the mindset of each role when implementing a specific task.

• Product Management
• Sensing -- giving voice to a concern over a breakdown in the community
• Envisioning -- design a compelling story about a future without the breakdown
• Development
• Offering -- committing to do the work to produce that feature
• Sales
• Adopting -- gaining commitments from early adopters to join the innovation for a trial period
• Sustaining -- gaining commitments from majority adopters to join the innovation for an indefinite period
• Implementation
• Embodying -- working with the community until the new practice is fully embodied, ordinary, and transparent
• Navigating -- moving ever closer to the goal despite surprises, contingencies, and obstacles
• Marketing
• Mobilizing -- building a network of supporters of the innovation from within dispersed communities

Many times over my career I've been assigned the job of getting multiple software development teams to adopt a practice; coding standards, secure coding practices, SOX requirements, architectural guidelines, etc. Eventually, the above 8 practices were performed but not always in an order that was useful. I got better with experience, but my life would have been easier if I would have had those practices written down to guide me. To make notes against. And to revisit when progress was slow or stopped. I hope you'll save the above list and use it for your future innovations.

References

Denning, P., "Avalanches Make Us All innovators," Communications of the ACM, Vol. 63, No. 9 (Sept 2020), 32 - 34.

Sorry, I don't have a reference for Metcalfe's Ethernet story. I heard him talk about it at a conference in 2015 or 2016.

Misbehaving

I've been listening to Misbehaving: The Making of Behavioral Economics by Richard Thaler on audiobook. In chapter 3, "The List," there is an interesting analysis of a company losing money because managers are afraid to lose their jobs. Which leads them to avoid some projects. I saw this only a little in my work experience.

In chapter 29, "Football," there is an analysis of how to game the draft to end up with an overall better team. Basically, it is chapter 3 but told in a more interesting manner. Replace the star football player with the star project and you get the same problem of putting all your resources in one basket. The analysis goes deeper and points out that the coaches and managers are not solely to blame. They are going after the star players (star projects) because these are what the owner (CEO/chairmen) want. I saw this more often in my work experience.

The higher up in a company the less the employee looked at the project data and the more they looked at what their boss wanted. If you are a manager, director, VP, C-suite employee, or chairman then please read this book. It won't give you answers but it might force you to acknowledge that you are making decisions based on the wrong data. Then you can give the company a better chance at [overall] success.

Okay, I know, I'm skipping over the problem of "the manager who doesn't work on the boss' pet project still gets fired." Yeah, that sucks. You deserve a better boss. But guess what? You saved your department for another year and only had to sacrifice yourself. Had you done the doomed project you might have doomed the department too.

Understand Risks Up Front

On any software project it is impossible to predict exactly what will go wrong. However, something will go wrong. In the early stages of planning, delineate the largest risks associated with your project. For each, quantify the extent of the damage if the risk potential becomes a project reality and also quantify the likelihood that this will come to pass. The product of these two numbers is your risk exposure with respect to that particular risk.

At project inception, construct a decision tree that delineates all the things you could do to lower the exposure. Then either act on the results immediately, or develop plans to implement various actions at points when the exposure exceeds your acceptable limits. (Of course, specify in advance how you will recognize this situation so that you can implement the corrective action before it is too late.)

Reference:

Charette, R., Software Engineering Risk Analysis and Management, New York: McGraw-Hill, 1989.

Avoid Standing Waves

One of the odd side-effects of keeping your plans up-to-date is the standing wave. In this situation, you always plan to update your plans over the next few weeks. Since projects that are behind schedule tend to get further behind schedule, this "update the plan soon" strategy requires larger and larger resources to be applied over the next few weeks. The wave gets larger and larger with no corrective action taken. Rescheduling and replanning in general require action, not just promises that things will be fixed soon. Just because you are only a few days behind, don't put off updating the plan. All projects fall behind one day at a time.

Reference:

Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.

Plan A Project In Detail

Every software project needs a plan. The level of detail should be appropriate for the size and complexity of the project. At an absolute minimum, you will need:

• A PERT chart showing the interdependencies among tasks.
• A GANTT chart showing when activity will be underway on each task.
• A list of realistic milestones (based on previous projects).
• A set of standards for writing documentation and code.
• An allocation of people to various tasks.

As projects increase in complexity, each of these requirements becomes more detailed and more complex, and other documentation becomes necessary. A project without a plan is out of control before it even starts. As the Cheshire Cat said to Alice in Wonderland, "If you don't know where you are going, any road will get you there!"

Reference:

Glaser, G., "Managing Projects in the Computer Industry," IEEE Computer, October 1984.

Allocate Appropriate Resources

Artificially constrained schedules and inappropriate budgets will doom a project regardless of the quality of the people or the availability of tools, languages, and process.

If you try to compress either schedule or budget, the engineers working on the project will not work efficiently, there will be no wiggle room when the inevitable slippage occurs, morale will suffer, and the project will probably cost more than what would otherwise be considered reasonable anyway.

In short, tightening a schedule or budget to land a contract or to get stakeholder sign-off will only ensure your failure to deliver. The goal isn't to get project approval. The goal is to get approval for a project that can actually succeed.


Reference:
DeMarco, T., "Why Does Software Cost So Much?" IEEE Software, March 1993.

Minor Underestimates Are Not Always Bad

Assuming morale has not been diminished, members of a project that is perceived as slightly behind schedule will tend to work hard at catching up, thus increasing productivity. Similarly, members of a project that is perceived as slightly ahead of schedule often take vacation days, work less hours, read their email longer, and ease up in other ways, thus decreasing productivity. In other words, the cost estimation itself will affect the project outcome. Any specific project may expend less resources if it is slightly underestimated than if it is slightly overestimated.

Be careful, though! If project members believe that the schedule is ridiculously underestimated or that estimates are underestimated on purpose, then morale and productivity will decrease. Worse still, you, as a manager, might start to gain a reputation of being incompetent, manipulative, or both. If that happens then project members will begin to perceive all estimates, even good ones, as bad.

As long as a minor underestimate is a natural occurrence then there is no need to worry that it'll effect the schedule. Team productivity has a certain amount of flexibility to compensate as long as there are minor overestimates to balance things out.


Reference:
Abdel-Hamid, T., and Madnick, S., "Impact on Schedule Estimation on Software Project Behavior," IEEE Software, July 1986.

Reassess Schedules Regularly

Schedules are usually set at the beginning of a project. These include intermediate deadlines as well as the product delivery deadline. As each phase is completed, the schedule must be reassessed. A behind-schedule project rarely recovers during subsequent phases. Thus, a project that is, for example, one month late at completion of design will be at least one month late for delivery. In most cases adding or removing people will only delay the project further. The most common technique is not to change the product delivery date. (After all, we don't want to disappoint the customer just yet; they might stop paying.) As each intermediate milestone is missed by an increasing amount of time, the time allocated to testing is reduced more and more. At the end, one of two situations is inevitable:

1. The product is shipped without the necessary quality.
2. The customer is notified of a very large schedule slip very late in the project.

Neither is acceptable. As a manager, your responsibility is to prevent disasters.

Instead, establish a working relationship with customers and/or management levels above you. Report every possible date change (usually a slip) and discuss the alternative strategies for overcoming them. The Agile methodology is very keen to cut out features in order to hit delivery deadlines. Only early intervention and involvement by all parties can prevent slippage escalation.

Reference:

Shore, J., Warden, S., The Art of Agile Development, O'Reilly Media, 2008.

Gilb, T., Principles of Software Engineering Management, Reading, MA: Addison-Wesley, 1988.

Believe in the Schedule

Probability of Project Success

Once a feasible schedule is established and appropriate resources allocated, all parties must believe the schedule. Engineers will not succeed in meeting a schedule if they don't believe it is realistic. The probability of success is more a function of faith in the schedule than its realism

The best advice is to have engineers set schedules. Unfortunately, this is not always possible. The second best advice is to involve engineers in the tough trade-offs that occur between functionality, schedule, and project abandonment. Few engineers would rather lose their job because a project is canceled than strive to meet a tough schedule.


Reference:
Lederer, A., and Prasad, J., "Nine Management Guidelines for Better Cost Estimating," Communications of the ACM, February 1992.

Know Before You Count

"Know before you count" is a software development management principle simply stated by Gerald Weinberg as, "Before you can count anything, you've got to know something." He is talking about the many people who count things in software but don't know what they are counting. He provides a great example. We have data concerning what percentage of the software industry is involved with maintenance rather than development. But can we recognize maintenance? Is a "new" development that completely replaces an existing system considered maintenance or development? Is a "modification" to an existing system that doubles current functionality and removes 95 percent of old functionality considered maintenance or development?

When selecting metrics for your project, make sure that what you are measuring relates to what you are trying to achieve. This often entails using multiple metrics. Remember: Even if everybody is measuring something one way, that way is not automatically right for you. Think about your metrics. Since everything can be observed (and in most cases measured), carefully select what you want to observe (and measure).


References:
Stark, G., Durst, R., and Vowell, C., "Using Metrics in Management Decision-Making," IEEE Computer, September 1994.

Weinberg, G., Rethinking Systems Analysis and Design, New York: Dorset House, 1988.

Collect Data Unobtrusively

Data collection is extremely important to help with future cost predictions, to assess the current state of a project or organization, to assess the effect of a change in management, process, or technology, and so on. On the other hand, data collection in an obtrusive fashion -- for example, if it requires software developers to do considerable extra work -- is meaningless because its collection affects the data itself. Furthermore, data collected from developers who do not want to provide such data will likely be useless because it is unlikely that an uncooperative developer will provide meaningful data.

The best way to collect data is automatically, with no developer-perceived interference. Obviously you cannot do this all the time for all data, but you should automate data collection whenever you can. However, you must be careful not to cross any lines concerning privacy. Respect your employees privacy and be transparent about what and how you collect.


Reference:
Pfleeger, S., "Lessons Learned in Building a Corporate Metrics Program," IEEE Software, May 1993.

You Can Optimize Whatever You Want

Any project can optimize whatever factor of "quality" it wants to. In optimizing any one factor, other "quality" factors are generally denigrated. In a landmark experiment conducted by Gerald Weinberg and Edward Schulman, five teams of software developers where given identical requirements, but each was told to optimize something different: development time, program size, data space used, program clarity, and user friendliness. In all cases except one the programs produced by the teams where rated best in terms of the attribute they were told to optimize.

If you tell your people that everything (such as schedule, size, maintainability, performance, and user friendliness) is equally important, none will be optimized. If you tell them that only one or two are important and the rest unimportant, only the important ones will be addressed. If you give them an a priori relative ranking, the ranking may not be appropriate in all situations on the project. The fact is that there are trade-offs -- different trade-offs -- to be made constantly during product development. Work with your employees and help them understand your priorities and your customers' priorities.


Reference:
Weinberg, G., and Schulman, E., "Goals and Performance in Computer Programming," Human Factors, 1974.

Huge Differences Among Software Engineers

Productivity (measured by lines of code per person-month) can vary by as much as a factor of 25 from the most to the least prolific coder. Quality (measured by bugs found per thousand lines of code) can vary by as much as a factor of 10 from the best to the worst software engineers.

I'm sure you can see my bias in the words above that I think quality is more important than productivity. Unfortunately, I don't have data to see the intersection of those two measures. I suspect that there is a correlation between productivity and quality. But with a diminishing return where the act of writing more code prevents a person from thinking about the stakeholder's true intention or the ramifications of the new code.

As a manager, you have to encourage an optimal mix of productivity and quality. This isn't done just by focusing on a single software engineer. This is a whole team project. For example:

• If quality is down then consider requiring stricter code reviews.
• If productivity is down then consider lighter code reviews.
• If both are down, is your team overworked?
• If both are down, is your team in need of training?
• And, yes, sometimes you do have to single one person out and say, "Slow down. You are making too many mistakes." Or, "Speed up. You are spending too much time testing your code."
• I've heard both of those admonitions. They helped make me a better developer. They helped me find balance between getting stuff done and perfectionism.
• etc...

There is no right way to optimize a development team's productivity and quality. But there is a wrong way - deciding everything for yourself. No one has all the answers and even if they did it would upset the team members to have no input.

Talk to your team! Show them the data that has you concerned and ask for input. Share details about the budget to explain why sending a few people to the QCon conference in Tokyo isn't feasible but the whole team could go to KCDC. Find ways to combine team building with training.

Reference:
Sackman, H., et al., "Exploratory Experimental Studies Comparing Online and Offline Programming Performance," Communications of the ACM, January 1968.

Brooks' Law

Measuring a project solely by person-months makes little sense. If a project could be completed in one year by six people, does that mean that 72 people could complete it in one month? Of course not!

Suppose you have 10 people working on a project that is due for completion in three months. You now believe your are three months behind schedule; that is, you estimate you need 60 more person-months (6 months x 10 people). You cannot add 10 more people and expect the project to be back on schedule. In fact, adding 10 more people would likely delay the project further due to additional training and communications overhead.

Approximately a decade ago, I worked on a big project alone. I approached it as proof-of-concept and focused on getting everything to work. Since ensuring that everything worked was my goal I didn't devote a lot of time to good object-oriented programming practices... I'm not going to apologize for that. I still think I did the right thing to ensure that the project worked. Half of the work I was doing was testing another team's API and helping them get it right. However, the project managers really screwed me over by announcing the project finished when reality I had only finished testing the API provided by the other team. My boss put 20 people on the project to finish it in the next month. This could have been a disaster but she did an amazing job coordinating everyone's efforts. While all those people were helpful with writing documentation and performing testing while the code was being rewritten. It really came down to one person, Charles Forsythe, who took the largely procedural code that I had written and turned it into high quality OO code.

This project would have gone more smoothly had we intentionally planned to throw away my prototype. Also, it is generally a bad idea to try to retrofit quality. It is either a testament that my prototype was of high quality code just not of the required OO paradigm and/or that Charles' coding ability overcame the difficulty of performing a retrofit.

The point of that story is that from the outside it looks like 20 people were thrown at the project to finish in a month. In reality, 1 person finished the project in a month and 19 people cleared the way and focused on tasks that multiplied that 1 person's impact. By doing it this way, my manager avoided the additional training and communications overhead. If they all would have tried to develop code for the project then it would have failed due to Brooks' Law. This isn't a guaranteed way around Brooks' Law but it is a good way to reframe development problems.


Reference:
Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.

Keep The Office Quiet

The most productive employees and companies have quiet and private offices. They have phones that can be silenced or diverted. They are insulated from regular, nonbusiness interruptions. Contrast this with the general industry movement toward open, landscaped offices, which reduce physical plant cost but dramatically decrease productivity and quality. Of course, the usual management line is that such an arrangement "facilitates communication." Not true. It "facilitates interruption and noise."


Reference:
Tank, A., Why It's Time to Ditch Open Office Plans, 07-Feb-2019. [Online]. Available: https://www.entrepreneur.com/article/327142. [Accessed: 22-Jan-2020]

McGregor, J., Open office plans are as bad as you thought, 18-Jul-2018. [Online]. Available: https://www.washingtonpost.com/business/2018/07/18/open-office-plans-are-bad-you-thought/. [Accessed: 22-Jan-2020]

James, G., Open-Plan Offices Kill Productivity, According to Science, 18-May-2017. [Online]. Available: https://www.inc.com/geoffrey-james/science-just-proved-that-open-plan-offices-destroy-productivity.html. [Accessed: 22-Jan-2020]

DeMarco, T., and Lister, T., Peopleware, New York: Dorset House, 1987.

Carry The Water

When your people are working long hours to get a software engineering job done, you should work the same hours. This sets the right example. Your employees will be more willing to work hard and do a good job if they know you are in the predicament with them. I had a software development manager, Karen Bolda, that did precisely this. It made all the difference in our attitude. During crises, Karen took on the role of "working for her employees." It worked.

If you can't help with the engineering work itself, let them know you are available to coordinate effort, run errands, order food, whatever they need. In short, carry the water.