Do you really need project management?

Our guest author Heinrich Drügemöller, Managing Director of the project service provider iatrocon GmbH, also opens his third contribution to the Can Do Blog with a provocative question. And although the answer can already be guessed - what is particularly exciting and interesting about this article are the case studies and derivations that can only lead to a "Yes!" from profound conviction.

In General

Before answering the question, readers should again consider what a project is. Suitable definitions are:

• A project is an individual, one-time, complex as well as temporally, factually and spatially limited undertaking with a specific personnel organization as well as clearly defined responsibility and tasks with a realistic target and result definition.
  
• According to DIN 69901, a project is an undertaking in which a defined goal is to be achieved within a defined period of time and which is characterized by the fact that it is essentially a one-off undertaking.
• A project can be large or small, but in any case it is unique, limited in time and requires a clearly defined result. It basically has one or more changes as its goal. Projects usually require resources. A project always involves people - in any number - (pure machine work is therefore not a project). A project has a "life cycle" with the following phases: Conception, Emergence and Development, Implementation, Conclusion and End.

 
It becomes clear that projects do not fit into a company's regular process. They have to be organized in parallel or separately. This brings us to project management. In recent decades, various methods have been developed for this purpose:

• IPMA, Association for project management 

• Prince2, (Projects in Controlled Enviroments) / also applies to product development
  

• PMI, Project Management Book of Knowledge 

• Scrum 

• SAFe 

• V-Model 

The list is not complete, and the methods have different focuses. However, they all serve - even if slightly differently - the basic requirements for project management, which I have summarized briefly as follows:

Requirements for project management

1. Ensure scope 
2. Monitor budget
3. Track deadlines
4. Track quality
5. Identify and monitor risks
6. Manage resources

However, paying attention to the above 6 topics is not enough. The 7th topic is particularly important: "Information management". This means providing information on all topics of the project for all stakeholders in a way that is appropriate for the addressees. From my point of view, these 7 topics show that the implementation of a consistent project management - no matter which method is used - is necessary. In my professional practice, I have encountered several examples of this necessity; I would like to explain two of them in more detail:

Example 1

Project management is carried out by a technical expert

An experienced technical expert without special experience in project management and PM training is given the task of carrying out a larger project. Several departments of the company are involved. Work is also to be outsourced to 2 external service providers.

After a good start, the project falls behind schedule. Critical meetings accumulate. Both service providers announce increased effort. Management ordered a neutral evaluation of the project, which resulted in the following:

Nach einem guten Start fällt das Projekt hinter den Zeitplan zurück. Es häufen sich kritische Besprechungen. Beide Dienstleister kündigen erhöhten Aufwand an. Das Management ordnete eine neutrale Bewertung des Projektes an, die folgendes ergab: 

Negative points:

The project brief is not complete::

• Risks are not listed 
  
• Goals are not "SMART" defined
  
  

The project structure is unclear: 

• Reporting and decision-making bodies not defined

• Responsibilities not clearly defined

Communication is not transparent:

• Stakeholders not identified 
• Management only partially involved 
• Affected team not fully informed 

• Project manager reports only to team leadership
  
  

The budget is not clear:

• External orders without specific tasks, deadlines, delivery items
• Internal budget (effort) not concretely defined
• No expense recording

Resources are insufficient:

• No resource agreements concluded internally
• Investments not evaluated and scheduled
• Fixed project manager permanently overloaded
  
  

The scheduling is incomplete:

• Schedule without milestones and resources
• Dates not maintained

Quality and test management is only partially implemented

Positive points: 

Project object / project content

• Technical well described
• Affected processes well recorded
   

Resource qualification

• Employees qualified and motivated
• Investments can be controlled in a timely manner
  
  

The conclusion from the evaluation makes it clear that the critical points are almost exclusively attributable to the areas of organization and management. In contrast, no technical deficits were identified. The management agreed with the recommendation and decided to introduce consistent project management. A reporting structure and decision-making levels were defined. Reporting of effort and documentation of results were agreed.

At the same time, it was determined that there was no project culture in the company. In the past, changes were mostly implemented in very small steps, which did not reveal the deficiencies in project management.

Lessons learned

Technical experts should not be forced into the role of project managers. While they are indispensable to a project, they often do not have the training or experience to be a project manager. They tend to see the technical things in the foreground. Project management and all the processes involved tend to be a nuisance for them.  

Management is particularly challenged in such situations. Project management requires time and budget specifications so that qualified work can be done. If technical experts are forced into the role of project managers, either project management or the technical work will be neglected. At this point, the technical experts can only be advised to consistently point out these interrelationships. 

Incidentally, due to the time requirement, it was decided in this example to carry out the documentation with office tools. The introduction of a PM tool was envisaged.

Example 2

A company decides to upgrade the software tools used throughout its manufacturing operations. The aim is to replace the software developed in-house by the company's own IT department over a period of 30 years. The first step is to sound out the market. However, a system suitable for the company's own production could not be found.

A renowned consulting company is brought in. After many consultations, the decision is made to create a complete set of specifications, in which the experience of the consulting company is also to be incorporated.

The operating situation at the time of the decision can be described as follows:

• Lack of resources in the IT areas
• Financial resources for IT are inadequate
• Departments are only able to provide a limited amount of resources for specifications
• A very large number of IT projects with priority 1 are in progress - some of them already behind schedule
• The IT portfolio contains almost 100 priority 1 projects (also a reason for the general update of the production software)
• High utilization of production capacity
• The goals defined at the start of the project guarantee an improbably high profitability of the new system when achieved
• Project management tools are not in use
• Project management methods are not used
• The tool of choice is Excel®
  
  

It is decided to start the project specification with the consulting company and a small internal team - 2 people. The company's own IT is not involved. An external project manager is appointed. His task is to manage the project.

In a period of just over a year, a specification with more than 600 pages and corresponding appendices is produced. Internal coordination of all teams took place. There was little feedback - which is surprising. 600 pages of specifications, partly written in keywords and enumerations, require a lot of time, which was actually not available due to the resource bottlenecks and the deadline pressure. The teams involved also expressed this.

The result of the internal coordination was presented to the management. It was agreed that the specifications should be regarded as a binding basis on which to base further measures.  

The "make or buy" decision was discussed and decided in favor of "make". An overall project was set up. A concept was drawn up for implementation. Planned duration: 5 years. The budget in the double-digit million range was set up and resources were planned. An agile implementation with iteration periods of 6 months each was to take place.

The consulting company involved was awarded the contract for the implementation. The IT department was only involved for the topic "interfaces". Concrete usable results were expected after about 2 years.

3 months after the start of the 1st iteration, the management demanded to achieve benefits faster. A proof of concept was decided. Rescheduling and delay of the 1st iteration was the consequence. The implementation concept was completely abandoned. There was increased effort for the 1st iteration. Test environments for proof of concept were not available and had to be reworked. At this point, the project duration was 2 years.

Lessons learned

After 2 years of project operation, the experiences are extensive. I divide them into two areas, concerning the project itself and the management, respectively:

Management

The company had no experience in implementing large IT projects. There was no transparent control of the smaller IT measures implemented to date. A portfolio of nearly 100 priority 1 projects does not make sense. No tools - except Excel® - were in use for portfolio management and project management. No project management method was implemented. Change management was not planned.

Measures

• Not making strategic decisions within an ongoing iteration that impact the ongoing iteration
• Implement a PM methodology
• Implement effective portfolio management with tool support
• Implement risk management
• Agree on a standard for reporting
• Introduce a PM tool
• Accompany projects through change management
  
  

Project

6 months for one iteration is too long. Usable results were planned only after 4 iterations (2 years). Project preparation in the company was poor. No development environment, as agreed, was available at the start. Productive settings were not supported by regular processes. Test environments were not available. The necessary IT infrastructure was not sufficiently available. Since the IT department was not actively involved, many misunderstandings arose. Resource commitment to the project was not binding, production was overriding.

6 Monate für eine Iteration sind zu lang. Nutzbare Ergebnisse waren erst nach 4 Iterationen (2 Jahre) geplant. Die Projektvorbereitung im Unternehmen war mangelhaft. Es stand keine Entwicklungsumgebung, wie vereinbart, beim Start zur Verfügung. Produktivsetzungen wurde nicht durch Regelprozesse unterstützt. Testumgebungen standen nicht bereit. Die nötige IT-Infrastruktur war nicht ausreichend vorhanden. Da die IT-Abteilung nicht aktiv eingebunden war, entstanden viele Missverständnisse. Das Ressourcen-Engagement für das Projekt war nicht verbindlich, die Produktion war übergeordnet.

Measures

• Fully integrate IT department into the project
• Clarify prioritization of the project
• Assign resources in a binding manner
• Set up IT infrastructure in parallel with the project
• Plan test and production deployments
• Provide development environments before project start

Conclusion

Project management can only be successful if it is introduced and understood within the company. Methodologically, project management should be clearly aligned. Project management only becomes effective when it is supported by tools. These relieve the burden on everyone involved and ensure transparency. Can Do is an excellent example of this.

About the Author

Heinrich Drügemöller is a senior project manager and managing director of the project service provider iatrocon GmbH. He has more than 35 years of expertise in projects and over 20 years of experience in corporate management. His industry expertise includes insurance and banking, utilities and energy, chemicals, pharmaceuticals, petrochemicals and transport logistics. He holds the PRINCE2 (Projects in Controlled Environment), PRINCE2 Practitioner as well as PMI (Project Management Institute), PMP (Project Management Professional) certifications. Heinrich Drügemöller is a guest author for Can Do