In the previous two articles we’ve talked about managing software projects. The first article focused on how traditional project management techniques fall short of addressing the inherent uncertainty in software development. The second article looked at three examples of increasingly nontraditional methodologies for addressing projects with high uncertainty. This last article boils down some of current themes and suggests some practices to increase the success rate for software projects.

Gleaning the advice from several different authors is fun. Definite patterns of beliefs show up and, more often than not, most good advice tends to be simple and straightforward. To be more successful in building software, do we have to adopt huge methodologies that require lots of time, effort, and money? Do we have to become converted to a “new way of life” and become zealots of a new order? Are the answers in forming massive, complex, matrixed teams that satisfy every conceivable process and requirement?

Well, if you are going for above the 90th percentile for guaranteed project success, maybe so.

But tremendous gains can be had for a lot less time, effort, and money and improve your probability of success considerably. That level of increase may be sufficient for your team or organization. The following is a simplified list of good practices or themes identified by the Software Engineering Institute, Steve McConnell, the Airlie Council, the Adaptive Project Management method, Tom DeMarco, Rob Thomsett, Alan Davis, and other authors. Most of these practices are just common sense. I’ve grouped them to make it easier to remember.

People are the Most Important Resource

• Hiring

The most significant factor in increasing project productivity is to have very good people.

• Antifragmentation

Project members who can focus for significant periods of time and who are not switching back and forth to other projects, will be far more effective contributors. (At least four authors identified fragmentation as the number-one enemy of projects.)

• Wisdom and Courage as well as Skill

Uncertainty in projects requires people who can see dilemmas, contradictions, inconsistencies, and conflict, and yet have the wisdom and courage to work comfortably in the environment. Uncertainty is no place for wimps.

• Dedicated Small, Permanent, Senior Core

Several authors emphasized the benefits of having good, proven, experienced people on a project for the entire duration, especially from the viewpoint of corporately learning to do projects better.

• Leadership

The project manager is a prime, if not the prime, focus of what the project is, what it does, and what it produces. They must be skilled managers, not just technologists.

• Match Project to Interests

People do better at doing what they’re interested in. Learn to reframe project activities to match people’s personal interest.

• Teams

Especially in an environment of high uncertainty, high risk, and high complexity, isolated individuals can not do projects. With an existing team, great care must be used in managing the team dynamics.

Learning is not a By-Product, It is an Objective

• Learning environment

Everyone needs to have the mindset that learning how to do the project is a significant goal in a project. No project lends itself to a formula anymore.

• Post Mortems

This is one of the most important practices. Post mortems must be periodic, formal, complete, and open, and must include the customers.

• Nothing Ad Hoc

Increased cycle time doesn’t mean not being disciplined. Disciplined actions, recognized and followed by the whole team, increase learning and adapting.

Make and Find Your Mistakes Early

• Reviews

You must have design reviews, code reviews, test reviews, documentation reviews, etcetera. One design error found in maintenance phase will cost 50 to 200 times the cost as when caught in the design phase.

• Timeboxing

This is a mechanism that encourages periodic releases and post mortems, high visibility for the whole project community, team learning, and customer involvement.

• Rework

“Rework” is work that’s done over again and includes fixing bugs, redesigning interfaces, changing for new functionality, recoding for requirements change, etcetera. Rework may be the most costly of all tasks that is almost totally ignored by current common practices. Instead, it must be recognized, estimated, and included in planning.

Make Little Mistakes

• Staged Delivery

Get something into the users’ hands as soon as possible, even if it’s a partial product. Get used to involving them, listening to them, and doing what they say. This may cause requirements to change and work to be done over, but the product will be significantly better in the long run.

• Minimalism

Create products, subroutines, functions, or elements that represent the minimal implementation of their function, no more, no less. Minimize the dependencies between modules or functions.

At Least Don’t Make the Same Mistakes

• Software Reuse

The most efficient way to produce software is to not have to produce it at all. This has the greatest potential for automatically creating products faster, cheaper, and of higher quality.

Customers are Your New Best Friends

• Project Identity

Customers who are involved have higher identity, more sympathy, make better contributions, add more excitement, and will be better resources when they are treated as collaborators.

• Continual Involvement in Reviews

Use customers, stakeholders, managers, and others to increase the corporate wisdom of the project, as well as sharing the adapting that takes place. Everyone gets to confront the tough issues.

Some of these practices are well known and have been around a long time. Some are newer and more innovative. They are all trying to improve the development of software in an increasing volatile, uncertain, and competitive environment. If our desires are to increase the fun, satisfaction, and effectiveness of projects, as well as continually improving our success at doing projects, these are worthwhile practices to learn.