A guest post by Bob Hughes, editor and co-author, handles project management for IT projects in the telecommunications, energy and local government sectors. He is an academic at the University of Brighton where he gained a PhD in software measurement.
Previously, in the Your Project Will Be a Success If… post I explained that the book Project Management for IT-related Projects, published by BCS The Chartered Institute for IT, had been designed to help novice IT project leaders grappling with their first project leadership responsibilities. The words project leadership, rather than project management, were used since the concern was not with the strategists in the boardroom, but with those who look after the actual development work that involves both technical and human issues. The idea behind the book was to talk about the basic approaches – which in a good project leader are often instinctive – that lie behind the detailed advice given in textbooks.
It comes down to quality
My advice in the previous post is about making sure you know why your project has been started. Let’s now focus on the idea that during the execution of an IT project, the project leader’s key concern is all about quality. If the software is wrong, then it does not work and the project is unfinished. When I reread my old posts, I often find grammatical slips or typos such as missing words – the last is embarrassing if the word is not. If, however, the general idea is clear, then nobody will seem too worried. In contrast, software is completely unforgiving. The smallest error can cause a system to crash.
Many urgent IT projects are pushed through under pressure, which can sometimes be brutal. In these cases, the design and build can seem to progress on schedule. Then at the integration and acceptance testing, everything falls apart. Testing is the most difficult part of the project to manage, since the work is governed by the unknown errors remaining in an often murky sea of code.
Keeping the IT product food chain healthy
IT development is a chain of activities where each new activity uses the products of the preceding ones and creates new products for use by later activities. For example, one activity makes a requirements document that another activity uses to make a design, which further activities use to produce code. The problem is that errors can enter the chain anywhere, joining others from earlier stages. Together they are passed through the remaining phases until integration and acceptance testing; or worse until people use the system. They then emerge into the light in all their ugliness. The later an error is found, the more difficult its removal, since you may have to go back several project phases to root it out and then rework parts of all the following stages.
A project leader wants to reduce rework to a minimum. You try to do this by eradicating faults entering the application under development as early as possible. The start of the anti-faults campaign starts with project planning. When you start planning, focus on the things that your project will make, not the things it will do. Some of these are deliverables handed over to hopefully grateful clients. There will be other, intermediate products, such as specification and design products created and used during the project, but not passed to the client at the end. A design for an application’s database would be an example of this.
Having identified these products, you can draw up a network diagram showing the products and the dependencies between them. This is effectively a description of the project’s development methodology. The links between the products identify the processes by which some products are transformed into others.
Fishing for errors in a murky sea of code
Strangely, it can be quite difficult to know what is actually going on in your project. After all, someone sitting typing at a workstation could be doing anything, including things that have nothing to do with your project. But products created can actually be seen and examined to ensure they will be a good basis for the next product-creating tasks. What you want is some way of checking the quality of each product. Most software products, including code, are documents, so one way is to get one or more people not involved in the creation of the product to read through them carefully. Pair programming in XP is effectively doing this in real-time.
For example, in Agile development, a common practice is to devise the test data and expected results needed to check that a software function is correct before the code has been produced. An advantage of this is that the calculation of expected results makes you think about how the software to be created is going to work in various sets of circumstances. Once the code has been produced, its correctness can be tested by running these test cases. But you also need a way of checking the quality of the test cases themselves. Someone needs to check that they cover all of the functionality described in the specification. Test cases are not tremendously glamorous, but they are as important to quality as the code itself: if there is an error in the operational system it means not just that the code is wrong, but that the test cases were defective as well.
And then the client changes their mind…
As if the project leader does not have enough to worry about, one of the biggest threats to the maintenance of correctness is change requests by the client. These will require the reworking of code and checking out that the changes made are compatible with the existing functionality. An obvious thing is to obtain extra time and resources to deal with these often tricky changes. But as noted earlier, not everyone does the blindingly obvious. Do everything you can to get this extra time.
As a project leader you may come under pressure to cut corners, for example to start coding before all of the requirements have been confirmed. You need to stick to your guns so that code development is done in an orderly fashion. Don’t expect thanks, but making sure the intermediate products are satisfactory is the way to keep the rework to the minimum and the project on schedule.
For more details about project management, see the resources below from Safari Books Online.
Not a subscriber? Sign up for a free trial.
Safari Books Online has the content you need
|Project Management for IT-Related Projects is the only textbook written specifically for the BCS, The Chartered Institute for IT, syllabus. Key areas covered include project planning, monitoring and control, quality control, risk and communications.|
|Shortcuts to success – Project management in the real world presents over 250 years of professional project management experience in a highly accessible format, thus helping project managers get up to speed quickly with good practice, avoid pitfalls and deliver business value. This fully updated edition reflects changes to working practices such as the use of social media and collaboration tools.|
|Project Management Bibliography is used to master Project Management, from basic, iterative and advanced Project Management techniques to the required tools to use to certification prep to useful toolkits and more through the use of Safari Books Online.|