The delivery metrics across your large-scale transformation program look strong. The closure report is signed off. The steering committee congratulates the team. And then, quietly, the organization continues doing things the old way...
How much do you challenge the directive? If project managers are always going to go along with what they are asked or told to do, then there really isn’t a lot of point in them being there.
Business acumen isn’t just something that executives or other higher-ups have—it’s a skill that project managers can access and exhibit on a regular basis and within each project, no matter the size of the endeavor or type of industry.
Compared to other engineering disciplines, software projects are more difficult to manage and deliver its end solution; the intangible nature of software, the lack of a software standard process as well as the rapid pace of technology advancement makes it a hard discipline to manage. Coupled with the fact that end users often don’t know what they want compounds the problem.
However, the key criteria used to determine the successful outcome of a project applied against other engineering disciplines are also applicable to software ones--they should be delivered on time, budget and quality, as well as meeting users expectations. But software projects have a poor track record of delivery--research by Standish group says that only 28 percent of projects succeed, while 23 percent are cancelled and 49 percent are challenged (very late, over budget or missing features…or all of these issues combined).
What can be done to improve delivery?
From a technical perspective
Developing software in an iterative fashion can be helpful in reducing risks inherent in software development. High-risk items need to be tackled earlier in the development process. Architecture is fundamental to a system (particularly large systems), so an architecture baseline should be produced early during the development process. If developing iteratively, this should be produced in an early iteration. The architecture should do what is expected now based on the customer requirements. One has to be careful that software developers do not start “gold plating” their solution with features they think the user or system might need in the future. This usually adds unnecessary complexity. Keep it simple and basic.
Applications should be built using component-based development. This will help you build applications that handle change better, allow reuse and can reduce maintenance costs. Generally speaking, 70 percent of costs of a system are when the project has been completed. Applications built using component-based technology simplify maintenance and are more cost effective. If you are not a pair programming, you should at least do code reviews. You will find a programmer will write better code if they know it will be reviewed. Reviews should take place frequently after a feature or bug is coded. Reviewers should help improve the code and their name should be added in the comments when the code is checked in. Reviews also improve knowledge sharing within the team.
In traditional waterfall development, integration is done late in the development cycle. This is very risky approach. A way of reducing such risk is to integrate and test continually, and not as a “big bang” as done in traditional development. Martin Fowler defines continuous integration as “a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems”.
This gives you rapid feedback and mistakes are corrected quickly. The three main steps for Continuous Integration (CI) are: 1. For all code to be checked in daily into a single source code repository by the team members; 2. Automatic build, which runs compiler scripts and reporting on success or failure; and 3. Automatic testing executes units tests for the code, and if possible run regression test.
Testing is usually an afterthought in traditional development. Agile development stresses the importance of testing by the concept of Test Driven Development. In TDD, an automated unit test is written before you write any code. The developer continually adds more test cases and makes them pass by writing the required code. TDD provides superior quality software and ensures that testing is at the heart of development and not something that is done at the dying stages of the development process.
Refactoring is improving the structure of components without changing its functionality. This improves quality and makes the software easier to maintain. It is important to have automated tests to ensure you have not inadvertently changed the behavior. Refactoring is particularly useful to do on critical or complex pieces of code.
From a management perspective
A large study showed that 45 percent of features created from early specifications were never used and an additional 19 percent were rarely used. This suggests we should do iterative development, which will allow us to…
1. Prioritize work optimally. We should tackle high-value/high-risk items first, high-value/low-risk items second and finally low-value/low-risk last. Avoid low-value/high-risk if you can. Traditional waterfall development encourages doing non-important activities--this is wrong.
2. Stay focused on continually delivering business value and executable software. At the end of the day, technology is there to make the business more successful--fast and incremental delivery is key.
3. Cater for changing requirements: Developing most modern systems will require changes and the development process and management required for this needs to be able to cater to it. Traditional waterfall approaches expect stable and non changing requirements. This is rare.
4. Iterative development provides shorter feedback cycles. This allows the following:
Risks are discovered and addressed sooner
You learn along the way (in traditional waterfall development, you often don’t learn until it’s too late!)
Testing is done much sooner than otherwise
Management can make tactical changes along the way
Estimates are often initially made with an incomplete understanding of requirements. Estimation is done at the beginning of the lifecycle before the requirements are defined (and thus the problem understood). How can you accurately estimate unless you know the problem we intend to solve? At this point, they often represent wishes rather than realistic estimates. As the project progresses and the problems become better understood, estimates should be revisited.
For example, NASA advocates re-estimation at defined points in the lifecycle. Unfortunately, many project managers know in their hearts they should revise their estimates as they get a better understanding of the requirements--but are afraid to do so because they feel they will be viewed as a failure. A project manager needs to be honest to themselves, their team and stakeholders.
It is important that the project manager is not bullied into setting a totally unrealistic completion date defined by a superior manager. It is a common mistake that project managers fall into and commit to unachievable dates, leading to failure and disappointment. In such situations, the manager needs to explain the key dimensions in project management: scope, time, quality, cost and risk. Altering these variables might allow you to achieve the date specified by the “bully” sponsor (scope and/or quality reduction).
Good project management is about managing expectations. You must not surprise your customer. There are many projects I have seen which are considered a big success despite the fact they have only delivered a small percentage of what was specified at the beginning of the projects, but they managed expectation obsessively.
Management often reacts to problems rather than being proactive to reduce the likelihood of such things occurring. A way to build a proactive mindset is to ask yourself (obsessively and every day) what you should do today to prevent your project from slipping in the future. For project success, it is important to have executive support; typically, each project should have a steering committee (or called Project Board in Prince 2 speak) chaired by an executive or project sponsor and consisting of senior user, supplier and project manager. Essentially, the steering committee maintains commitment and involvement of business management, makes decision of the scope and direction of the project and resolves issues in a timely manner.
Some of the points highlighted in this article are obvious. However, I’m surprised how many of these mistakes continue to flourish in our industry leading to failed projects.
Sanjeev Khurana is Head of Development at a large European Investment Bank and has over 20 years of IT experience. He has also been a part time lecturer at Universities such as Brunel, Middlesex, Greenwich.
