Posted on by & filed under Content - Highlights and Reviews, Information Technology.

code 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.

This is the first of three posts about what I think are key lessons for novice IT project leaders.  Note that I said project leaders, and not managers. So this is not for the directors of multi-million euro/dollar/pound programs, but for those who look after the actual development work. The high-level director may have strategic vision, but could well be a generalist who delegates responsibilities about detailed technological and business issues. Leaders of the software development teams, whether they like it or not, find their noses rubbed in technical concerns.

Project leaders will also have to deal daily with other human beings in their teams, most of whom, hopefully, will be great, but some of whom can be awkward.  Guidance on project management often offers step-by-step processes. I hold up my hand and admit that I have been responsible for some of these. But the good project leader is likely to have some useful general attitudes and approaches, and it is these I want to focus on.

Help for Novice Project Leaders

The book Project Management for IT-related Projects published by BCS, The Chartered Institute for IT, was originally written by a team of project management trainers. I had the privilege of editing the contributions to the book. The team was not trying to come up with some startling new approach to IT project management. It was simply trying to convey a clear and practical explanation of accepted project management good practice to novice project leaders. Typically, these project leaders were wrestling with their first project responsibilities.

The book is full of practical steps to deal with various aspects of IT projects, but usually these are examples of broader guiding principles. For example, if I had a time machine and could email my younger self, I would certainly tell them: always make sure you know exactly why the project you are working on has been started. This is particularly important if you come from a software development background. All you really want is a good clear specification so that everyone can get on with the job. As a project leader you quickly learn it is easy to upset people, and so you want to only annoy those you really have to. Your senior management and clients are all very busy people (and they always are), so you may not want to hassle them with questions about the background to a project. You may hear things like, We’ve wasted an awful lot of time arguing about what needs to be done: what we need now is for you to get stuck in. But you need to ask questions.

Uncover the real project reason

My first independent project responsibility was a very small one when I worked for an unglamorous local authority in London – are there glamorous ones? They had a lot of small accounting systems that dealt with incoming payments from a multitude of sources such as burials, and these – the payments not the burials – were run on antiquated computing equipment. The summarized details were then transferred manually to a sophisticated mainframe system. They wanted these little systems to be transformed to run on the mainframe as well. My small group beavered away producing clever code to do this, and it took a week or two longer to complete than originally planned.  When the work had been completed I learned that the reason for the project was not to produce a swish new accounting system, but simply to get rid of the computers in order to free up expensive office space. When we had asked the current users what they wanted, they probably asked for extra features just because they could see our eyes light up at the thought of a juicy coding challenge – but no one mentioned the most important reason for the project.

So on page 3 of our book it says you need to identify the “key project success criteria.” You could do this by typing up a document with bullet points under the heading The project will be a success IF…. The things on this list are practical things that your team can achieve. More products are sold may be a good business objective. Perhaps your team is going to create an ecommerce system and this can enable more sales. But other factors will also influence the number of sales, such as the things sold being things people actually want. Customers can buy products online would be more to the point here.

Also, avoid just listing activities, for example: The project will be a success IF requirements are gathered, the system is designed, etc. What you should be interested in at this point are the end products of your work, not the way the products are to be created. In the case of the ecommerce system for example, it might be better to acquire an off-the-shelf system, rather than build it from scratch.

With almost every project, key objectives will include the delivery date and the overall cost.

Don’t dismiss the obvious

When I try to hammer home the need for clear shared objectives, some just dismiss this as stating the obvious. But it is amazing how people don’t do the blindingly obvious. One problem is that the business side of an organization can have a sketchy grasp of IT, and the IT people can be vague about the ins and outs of the business. So this means that people are not really understanding what is going on when the business and IT meet. They just hope someone else understands.

Enquiries into failed government projects invariably identify unclear or conflicting project objectives as contributing to project failure, so this is clearly a problem at the top as well as at the more lowly levels of IT development.


I hope you will find the points covered in this post helpful for managing your next project. Remember to make sure you know why your project was started. Stay tuned for the next post when I cover the importance that quality plays in a project.

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.

Tags: BCS, project management, success, The Chartered Institute for IT,

Comments are closed.