Over 70 per cent of software development projects go significantly over budget or are late. Many end up cancelled. The root cause in most projects can be traced to work done incorrectly, or not done, during project start-up.
The key factors that contribute significantly to the potential success or failure of a project are the following:
Defined scope. The most important factor for success is a clear definition of the project’s boundaries. Without this, a project has little hope of being on time or on budget.
To accomplish this, you need to agree on a clear definition of what functionality will be included in the application and what activities the project team will be responsible for (e.g., development, testing, conversion, and writing training materials). Next, the responsibilities of the user community or other departments (e.g., training, organizational change management and installation of software) need to be defined.
It’s also important to use checklists from standard development methodologies to anticipate the various activities and deliverables that will be required, and to contain scope early in a project when the total functionality of the system is not known, by using bounding conditions such as maximum effort, time-boxing, function-points, or screen and report counts.
Treat the definition of scope as a contract whether or not you will actually require a legal contract. Also, define procedures for handling scope changes before you begin work on the application.
Realistic plan. Create a detailed project plan that is realistic. Work closely with your sponsor during planning to build commitment. Invariably there will be pressure to reduce your time and effort estimates. If your plan is realistic, resist the pressure. Instead, work with your sponsor to reduce scope. If you do not, you will likely end up delivering late and going over budget.
If the business case for the project does not justify a realistic plan, then you and your sponsor should put the resources into another project that will give the required benefits. It is a mistake to cut estimates in order to get a project approved.
Competent team. Don’t try to staff your team with only world-class developers.
You may say, “but don’t we want only the best resources?” The answer is, surprisingly, no. You need a few visionaries and experts on your team, but the rest should be made up of stable, dedicated, team-players. An entire team of thoroughbreds is very difficult to manage because highly capable technical staff often require a lot of attention and constantly need new challenges.
Make sure that you have the right team composition and think through how the team will be structured as it moves through the project’s phases. It is essential that each team member have a clearly defined role distinct from others on the team.
Managed expectations. Projects can de-rail if expectations for them are too high. Users may be sold on large savings or significant increases in sales or productivity within a short time. When reality arrives, it is not possible, or too expensive, to automate functions that were promised and users become disillusioned. From the beginning, undersell and over perform.
Make sure that the communicated vision for the system is fully attainable within the project’s budget and time frame.
Infrastructure. The project team needs the appropriate tools and facilities to do its job. A project can fall weeks or months behind schedule before it is even started when the team has to spend time trying to get office space and set up its work environment.
If a project starts off in the wrong direction it is sometimes possible to take corrective action to set it right, but it is always far better to get the right start.
Hughes is vice-president of software development for EDS Systemhouse in Toronto. He is currently project director for Ontario’s Integrated Justice project. He can be reached at [email protected].
