All projects need to be managed, but software projects present particular challenges due to the intangible nature of the deliverables, which are typically lines of code. Unlike construction and many other projects (which were the subject of Part 1, the bid process; Part 2, contract negotiation; and Part 3, construction management of this series), a rough estimate of progress can’t be measured at a glance, making the project schedule especially difficult to monitor.
Although software projects have important differences from more conventional undertakings, the official definition according to the Project Management Institute remains the same: “A project is defined as temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.”
Like all projects, software projects need to be performed and delivered under certain constraints, often illustrated using the project management triangle:
- Scope: includes the features and functionality of the end product and defines what must be done to produce the project’s end result,
- Time: the amount of time available to complete a project
- Cost: the budgeted amount available for the project
These three constraints are often in the competition so a change in one side of the triangle has an effect on the others: increased scope can increase time and cost, a reduced timeline may result in adding more resources thereby increasing cost or reducing the scope and a limited budget may require reducing the scope and extending the schedule. The end product’s “quality” or “performance” is often a fourth constraint inherently managed when all three constraints are met.
The discipline of project management provides tools and techniques enabling the project team (not just the project manager) to meet project constraints. All resources, including the client’s, must be expertly managed to deliver on-time and on-budget results and this requires a defined methodology.
Software project management requires bringing together two or more organizations to form a team in order to attain a common business goal. If the software is developed in-house, then the organizations are the company’s IT and business departments. If the software services are purchased, then the company creating the software must work with the client’s IT and business groups.
To illustrate all of the above points, consider a real-world example, namely, implementing campaign management software and services purchased from an outside supplier through a client’s marketing department. The software will be integrated into the company’s IT infrastructure and used to identify/target customers and ultimately increase revenue.
The Business Point of View
As with many software projects, the customer’s team in this example didn’t fully appreciate the complexity of the required hardware, security and integration efforts. They were, instead, solely interested in the ultimate deliverables which were viewing, transforming and analyzing customer data; and creating and distributing reports for executive decision making.
The client wanted to make business decisions based on the effectiveness of marketing campaigns tested on existing and potential customers. Data from the complete cycle of customer interaction/feedback was to be brought back through the delivered software system for effective management and updates of future campaigns. Requirements include:
- Access to real-time customer data and responses
- Functional software to analyze data and create reports
- Ability to schedule jobs and send campaigns
- Ability to distribute and share data and reports
The first task was explaining the project tasks and durations to the customer as the marketing managers wanted virtually instant access to information and reports—and didn’t understand wait times required for ordering hardware, installation, configuration and testing of the campaign tool and custom programs.
Once this was accomplished, a schedule was created and agreed upon by all parties, allowing the project to commence. Although the client’s business group now understood the schedule and deliverables, it was still necessary to satisfy another entity within the client’s organization, the IT department.
IT’s Point of View
While the client’s marketing department was only interested in the end product, the IT group managers were concerned with many implementation details along the way as most would directly affect their existing systems. Some of their leading concerns were:
- Hardware requirements including cloud-hosted solution options
- Choice of the operating system: Unix, Linux, Windows
- Network topology
- Integration with databases and other files: SQL Server, Oracle, Teradata, DB2, Excel, flat files, third-party data, etc.
- Security layers: authentication and authorization
- Performance
- Capacity
- Custom configurations
- Software installation, upgrades and fixing defects.
Reviewing the above project management, business, and IT requirements—it’s easy to see why many software projects fail. First, there’s the intangible nature of software, which makes tracking progress extremely difficult. Second, the client’s business unit, in this case, the marketing department, often has little or no understanding and appreciation for the required effort. Third, the client’s IT department has standards that must be met and requests that must be dealt with. Not surprisingly, this leads to a poor track record for software projects within the industry.
Why Software Projects Fail
According to the Institute of Electrical and Electronics Engineers (IEEE) article, “Why Software Fails” by Robert N. Charette, of the IT projects that are initiated, at least 5-15% will be abandoned before or shortly after delivery as its hopelessly inadequate. Many others will arrive late and over budget, or require massive rework. In other words, few IT projects truly succeed.
Analysis of unsuccessful software projects shows common causes of failure:
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project’s status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project’s complexity
- Sloppy development practices
- Stakeholder politics
- Commercial pressures
Since project issues like those listed above and others are inevitable, applying project management methodologies to uncover issues early is critical. Producing precise documentation is time-consuming but necessary to ensure business and IT requirements are aligned, and to ensure project stakeholders are informed.
The project manager’s number-one priority is to keep the project moving forward and toward closure. Identifying issues and risks early and having a risk contingency plan will help get past obstacles, as it is critical to stay on schedule.
Towards that end, a library of project management templates should be created to ensure consistent project documentation. As recommended by the Project Management Institute, this documentation should fall into the following five groups:
- Project initiation
- Project planning
- Project execution
- Monitoring and controlling
- Project closure
Why Projects Succeed
Although many software projects fail, many succeed. Why?
First and foremost, the entire project team was highly skilled, motivated and committed to the project. Without their efforts, success wouldn’t have been possible.
The project manager’s technical background in software programming allowed the project’s programmers to be managed and for their progress to be effectively gauged. Periodic project and code reviews helped to identify skill sets lacking on the project and then allocate additional resources as necessary to stay on schedule.
The same technical background allows managers to effectively interface with IT and mollify their concerns regarding integrating software products and programs with existing systems to meet end-user needs. Finally, experienced project managers are well equipped to explain the project’s technical and infrastructure requirements to the client’s marketing department such that they were satisfied with the schedule.
Dan Hebert, PE and Kevin Fullerton, PE
Author:
Dan Hebert, PE, and Kevin Fullerton, PE (Originally published by IHS)