Project Leadership is Critical

The most important person on a project is the project manager. A good project manager with a supportive management style can make a project, and a bad one with an aggressive management style can single-handedly cause it to fail. I have seen both happen. As an ideal, the project manager will have personal technical experience that matches functionally the work being performed on the project. For instance, if it involves requirements elicitation, he/she should have personally done that kind of work. In a cradle to grave development effort, the more technical breadth that individual has the better. They absolutely must have excellent writing and presentation skills, and must be able to interface with both the customer and their own line management. The project manager has to have had management experience, some of which should be at the level required for the project.

After that, it is critical to select a high quality set of senior analysts for the project. This includes both business analysts and systems analysts. These people must have the requisite technical skills and experience to match the project’s needs. For example, a project might need senior analysts with skills in requirements management, database management, system architecture and design, and system testing. At a minimum, they must have successfully done the type of work to be performed. If specific tool sets are to be used, in the ideal they will have worked with those tools. As with the project manager, communication skills are a must. In addition, some supervisory experience is needed. Ideally there will be some experience overlap. For instance, a person with both requirements management and system testing skills is more valuable than someone who only has requirements experience because they can cover for a missing system tester.

I will call this set of people the Leadership Team.  The Leadership team must be individually flexible, and able to work together as a team. That is, they must be team players. Positive interpersonal dynamics among this set of key people must exist. Achieving consensus should be more important to them than individual heroics. If the team clicks, and they work together synergistically, the whole does indeed become more than the sum of its parts. In my experience, it is impossible to completely staff a project with super stars. They just are not going to be available when needed, and the cost is prohibitive. But given the existence of a synergistic leadership team, it is quite workable to use journeyman, and even some junior level staff for all remaining project functions, provided that the Leadership Team monitors and mentors them.

The reverse of the staffing coin is to ruthlessly cull out poor performers or discontents at any project level or role. These people can directly cause technical problems, and they will indirectly adversely affect project morale. If they are allowed to linger on the project they can and will make costly mistakes and they can and will negatively impact the performance of other project team members. It can be really painful to dump a malcontent, especially one who does not want to go. HR departments do not like wrongful termination suits no matter what the merits. Regardless, suck it up, and do what it takes to get rid of them.

Partner with Your Customer

To bring a system into existence, there is generally a project organization that is doing the work and a customer organization that has a need for a system and is financing the project.  In my personal experience the customer has been a government agency, which provides the experience base for this discussion. Unfortunately, as many have experienced for themselves, there is a tendency for the customer to try and dominate the customer-project relationship. All too often the customer tries to rule by intimidation and, all too often, they force non-optimal technical decisions. This creates a jointly adversarial relationship. And that causes poor project morale, lackadaisical effort, and high project turnover. Results are typically poor. In short, you can have a great project team and still fail due to the customer not holding up their end.

To improve the project’s chances of going smoothly, those two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative. When real partnering does occur, and both sides hold up their end of the bargain, results tend to be excellent. Technical people enjoy their project; they work harder, and they stay around. The customer tends to get a more user-friendly system, which they are happy with. It is a win-win situation.

Most of you will have only worked the project side of this relationship, and if you are lucky you may know what partnering looks like from the project side.  I have personally worked both sides of the fence. Here is what partnering looks like from the customer perspective.  It starts with the RFP. That document is well written, and expresses exactly what the customer expects the project to do and deliver. If a set of system requirements is provided with the RFP, it is professionally produced and clearly and fully expresses what the system is to do without forcing major design decisions. This will allow the project to correctly estimate project costs and make proper staffing decisions. On startup, the customer provides a briefing to the project staff, at which time any applicable existing documentation is turned over to the project. The project is invited to do its own briefing on how they plan to do the work. If on-site, adequate space, workstations, and connectivity are provided on day one. Even if off-site, some dedicated space, including a small conference room is provided. Technical questions and issues posed by the project are promptly and fully addressed. Access is provided to potential users, either for requirements elicitation (the ideal), or requirements validation and expansion.  Customer people attend all project briefings and project peer review sessions to which they are invited. Deliverables are promptly and thoroughly reviewed, and well-written formal comments are provided to the project. If needed, meetings are held to resolve conflicts. If the project is big enough, joint configuration control and risk review boards are formed.

On the project side, transparency is critical. Nothing is hidden from the customer. Any problems encountered are promptly conveyed to the customer for joint consideration. Schedules are rigorously met; documents produced are of high quality, including lack of grammatical or spelling errors; emerging user interfaces are offered for user review, and appropriate adjustments made; staff of the appropriate quality are placed on the project and vacancies are promptly filled.

Look for Part 3 of this series in the next Business Analyst Times online in mid-February.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management.  He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University.  John is the “Project Whisperer”.  His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

 © John L. Dean, 2008