Title: From the Coalface

Having been involved in about forty software developments over the last ten years, I have come to the conclusion that the biggest problem facing software development (in the IT world, anyway), is The Project Manager. Almost without exception, every Project Manager I have come across has been incompetent to hold the job. As the Project Manager is often the ultimate decision maker on a development, all problems which arise as a result of poor analysis, design and implementation, resulting in the project going over budget and being late are his/her fault at the end of the day, but who actually gets the blame? The programmers, more often than not!

I believe as an industry we desperately need a new kind of Project Manager, but to produce a profile, we need to identify the factors that lead to successful development projects.

Successful projects do not come from the using the latest CASE tool or automated test suite; indeed, these often waste enormous amounts of time and can force a project down a disastrous route. Successful projects do not come from an onerous Quality Management Systems or ISO 9003 accreditation; this can just weigh the project down in documents and can still force a project into an unworkable method.

So what's the answer? Well, I am originally from the world of 'nuts and bolts' engineering, and I realised many years ago that 'good' engineering comes from the application of knowledge in all activities of an engineering project.

It is the job of the new type of Project Manager to ensure that the staff of the project have the appropriate level of knowledge to do their jobs effectively, and to manage the engineering processes so that the staff are able to do their jobs effectively. All this has to be within the project's time and financial constraints.

I believe that the new Project Manager must have a minimum level of knowledge of analysis, design, programming, testing, configuration management, etc. to be able to understand the dynamics of software engineering processes, so that he/she can be an effective manager for a particular project; however, he/she does not need to be an expert in any of the processes - the staff are the experts.

Before all the QA Managers rip me apart, I would say that standards and procedures have an important part to play. The reason for standards and procedures can be stated very simply as 'To avoid repeating the mistakes of the past', therefore I would expect my new Project Manager to be very familiar with Standards such as IEEE 828, 829 and 830, TickIt and ISO 9003 as a minimum.

A little trick, which I employ at interviews, is to look at what reference books are lying on desks being actively used by staff. If the development is re-usable components and C++ but there isn't a copy of GOF or 'Software Re-use...' (Jacobson, Griss & Jonsson) in sight, then I get nervous. I also ask questions about books if I'm interviewing for staff myself. I have found this to be a good indicator of the level of knowledge, especially with Contractors.

Now for some horror stories :

One development in particular stands out, where the Project Manager insisted on his way of doing things despite every technical person involved proving to him that there was no way on this earth that the project could complete if they carried on in that manner. I left as soon as I could, and the project went bust, very nearly taking the software house with it. The Project Manager was finally sacked, but the real tragedy was that nearly thirty others lost their jobs as a result, through no fault whatsoever of their own.

Then there was the project where the Project Manager decided there wasn't time for Requirements Engineering, the project would jump straight into Use-Cases and implementation-level class design, so there wasn't a single Analyst on the plot. This was a product that fell into the Computer Supported Co-Operative Working category, and had very long Business Transactions involving several Internal Workers to complete a transaction. Each Business Transaction had up to fifty possible paths, and those were only the ones I knew about! This project went belly-up big time, but I was long gone...