Managing Projects
Project management is almost all about control. Outcome, cost and development time must all be predictable. Our experience tells us, however, that they seldom are. But projects are also about people, relationships and personal development, which we often forget.
As a Project Manager you have the odds stacked against you. The customer puts tremendous pressure on you. Your own management rarely supports you when you need to. You never have enough resources, and the resources you have haven’t got the right competence. The time schedule is impossible from the start, and you never know what the customer really wants.
But there are things you can do to even out the odds. Knowledge about what makes the difference is one factor that separates successful Project Managers from not so successful ones. Doing the wrong thing can have catastrophic consequences for your project and for your career.
Some Project Managers misunderstand their own mission. When requirements are unclear or absent, they put on themselves to find out what the customer wants. This is understandable, someone has to do it, but it is a recipe for disaster.
While developers are floating aimlessly in the project, the Project Manager spends hours and hours in project meetings with the customer, trying to make sense out of functionality and time schedule. The task is futile, because the Project Manager often lacks the technical knowledge; and to be honest: the task is not for one person to cope. No Minutes of Meetings are written at these meetings, and what was really agreed upon is vague to say the least.
The role of the Project Manager has become to interpret the needs of the customer to the project. None of this information is however documented, and with huge gaps in their knowledge, the designers are forced to make a “best guess”.
In reality the project has no manager. Resources are not managed, plans are not prepared, processes are not in place, and documents are not written or reviewed. Instead of using the inherent capacity of the project to solve all these problems, the Project Manager devotes all energy to find out what the customer really wants.
A recipe for disaster – part 2
As a remedy to the problem that the Project Manager spends most of his or her time with the customer, some projects assign a second Project Manager to take care of things at home. This home based Project Manager is sometimes called a “technical” Project Manager, but is in reality the real manager of the project.
Another variant is to assign a Systems Engineer to assist the Project Manager in the task to sort out the product requirements.
If a proven method is used to systematically capture requirements, this organisation may save the project from certain disaster. The solution is, however, not the organisation itself, but the systematic approach to the problem. Activities (what needs to be done) are always more important than roles. Staffing a project with two Project Managers (instead of one) does little for the outcome of the project.
When organisations experience problems with their projects, they sometimes change their project model. But the desirable results keep eluding the project. Changing a project model solves little in reality. Projects need more than a project model to succeed; they need processes for working with requirements, design, implementation, test, configuration management and quality assurance. There are three crucial processes that you, as a Project Manager, need to put in place in your project above anything else: Requirements Engineering, Configuration Management, and Test Engineering. These processes are even more important than the Project Management process itself!
As a Project Manager, you have to separate between requirements on your project, and requirements on the product or service you develop. Project requirements (or project goals as we also know them) are about time schedule, budget, resources, personal development, quality assurance and processes to be used in the project. Some Quality Standards talk about non-technical requirements, but it’s the same as project requirements. Product requirements, on the other hand, are about functionality, interfaces, portability, maintainability, reliability and all other ”ilities” there is for a product (or service). You never mix project goals with product requirements, either in documents or in processes. Product requirements live as long as the product is alive, and they will evolve with new releases of the product. Project goals, on the other hand, go dead when the project terminates. No one is interested in project goals after the project is concluded, except maybe for statistical use.
The project model is first of all about management and fulfilment of the project goals. The test process, on the other hand, is about showing the existing quality of the product, by ensuring that all product requirements have been met. Managing projects is therefore management of the project goals.
The lack of control
There is a constant lack of control in projects. Most Project Managers compensate this lack of control by focusing on the date of delivery. If the project delivers on time, the project must be under control, right? Wrong! Project control is much more than delivery precision. It is about budget; about making sure the project has enough resources, about performing code and document reviews. It is to ensure that processes are in place and to make certain that quality goals are met.
In general, it is easier for a Project Manager to have control over internal project matters, such as quality problems, than having control over external conditions, such as changing requirements. The customer can be hard to control, his business nearly impossible. Conditions and requirements can change fast, and the project needs to adapt without the loss of control. This balance can be difficult to keep, and control is often sacrificed in favour of flexibility.
Project goals are often found in the Project Specification, the Quality Plan or the Configuration Management Plan. These project goals can be viewed as requirements on the project. Some Quality Standards talk about technical and non-technical requirements, where non-technical requirements are the same as project goals. Here are some examples:
-
•Budget, person-hours and money;
-
•Time schedule;
-
•Where the project should spend its time (e.g. in project meetings or writing requirements);
-
•Human resources, competence and number, development of HR;
-
•Tools and equipment (these are also resources);
-
•Project organisation, usage of processes;
-
•Quality assurance, reviews, organisation, escalation and handling of quality issues;
-
•Failure reports, number of and time to process/correct;
-
•Change requests, number of and time to process;
-
•The feelings of project members, during and at conclusion of the project.
Some project models talk about both goals and objectives, often without explaining the difference. We have all learned that goals must be measurable, we are told this all the time, but this is strictly not true. A goal doesn’t have to be measurable, and sometimes it shouldn’t be. For a software project this can mean: “the time to process and correct a failure reports should be short”. The objective of the goal can be “seven days”. If a goal is not measurable, one or several objectives can be defined for that goal. The goal can even have Key Performance Indicators (KPI’s) attached to it. A strictly measurable goal can sometimes blur what the project is really trying to achieve. In our case: long delays in the processing and correction of failure reports could be harmful to your product quality, because people forget. When you have one million things to keep track on, it is not easy to remember what the failure was about, or what you did to produce it. Goals should help to explain why things are the way they are. The truth is that the simple fulfilment of objectives and KPI’s doesn’t necessarily create the wanted behaviour in the organisation.
