Drawing a line Between Software Development and Project Management

Fifty years ago, the typical information technology (IT) project finished later than planned, cost more than was budgeted, and produced less functionality than the user wanted. Much has changed in the intervening decades:

• The role of data processing manager (reporting to the controller) has evolved into that of Chief Information Officer (reporting to the CEO).
• The corporate computing resource has grown from a single, standalone mainframe used mostly for payroll and accounting into a complex operation that includes thousands of interconnected machines used for everything from customer relationship management to the occasional game of solitaire.
• The IT department has been transformed from an administrative backwater whose workings were of little concern to most executives into a high profile organization whose success is critical to corporate survival.

Despite such major improvements, many IT users remain dissatisfied. What prevents the IT department from delighting their customers? While it is not the only issue, one major contributor is the failure to distinguish between software development practices and project management practices.

Understanding the Differences

The relationship between software development and project management and is similar to that between marketing and sales. Software development is like marketing — it is a strategic discipline concerned with what you must do to be successful:

• What is the best way to identify user requirements?
• What must be done to meet relevant quality standards?
• What technology should be used to support each application?

Project management is like sales — it is an operational discipline concerned with how to be successful:

• How should the team be organized?
• How long should the work take?
• How can you tell if you are on schedule?

As with marketing and sales, skill in both disciplines is necessary for success. For example, most software development approaches identify customer involvement as a critical success factor (what must be done) while the project management approach to this issue focuses on which specific customers will be involved (how it will be done).

Admittedly, there is some overlap between the two — that's why I used the Yin-Yang symbol at the top of this article. Many software development approaches provide some guidance on estimating and scheduling. Both disciplines place great emphasis on producing a quality product — one that both conforms to the specification and is fit for use. But despite the overlaps, it’s important to understand the differences between the two disciplines because poor practice in either area can result in a failed project.

Apples and Peach Pits

I once attended a presentation by a senior manager of a leading IT consulting firm. He noted that many companies were losing substantial chunks of market share to more nimble competitors because of their inability to develop mission-critical systems in a timely fashion.

The problem, he said, was that software developers needed a “whole new approach to project management.” But the practices he wanted to change were those of highly structured, traditional software development approaches that equated the quantity of paper with the quality of the system. He didn't need new project management. He needed a new approach to software development.

By failing to understand the differences between the two disciplines, he cut himself off from some simple truths that are readily available in the project management literature. Even with a more efficient approach to software development:

• His clients’ approach to resource estimating would still produce estimates that were less than half what was really needed.
• His clients’ approach to scheduling would still produce schedules that had less than one chance in a million of being met.

A better approach to software development might reduce the cost and duration of his clients' projects, but they would still be unhappy because their projects were still late and over budget. In the absence of predictability, management's plans will have little chance of success.

A Case of Misidentification

In another example, I read an article that suggested using “prototyping as a project management technique.” The article was an analysis of the potential for prototyping to reduce project duration. The clear implication of the article was that a “project management technique” was anything that would reduce project duration. The author was mistaken. Project management’s charter is to make the process predictable and reliable. Good project management can often shorten project duration, but it does so by helping to anticipate and avoid problems that could cause delays. Prototyping was, and is, a software development approach.

Conclusion

In both of the above situations, experienced software developers confused software development approaches with project management practices. In doing so, they cut themselves off from a significant body of practice that can help them respond to today’s demanding environment. Modern project management affords:

• Better scope definition to minimize last minutes surprises
• More accurate estimates to ensure that the most critical projects get the resources they require
• Improved progress measurement to support appropriate mid-course corrections

Every software developer (and most CEOs) have a favorite horror story about a system or product that took months or even years longer than expected — or one that was so full of bugs that it was virtually unusable. Some of these problems were caused by the software development approach; others were caused by poor project management.

Preventing future problems requires accurate identification of the causes. IT managers who have a better understanding of the differences between the two disciplines will be better able to help their IT departments contribute to their company’s overall organizational strategy.