On Project Management
The project requests, which have reached me in the last time, differ from those of previous years – project tenderers still require experience in one or optionally several of the known project control methods (Prince2, PMI etc.) provided.
However, I think to have noticed that project tenderers put less weight on a particular methodology or certification („nice to have“). With regard to these project management methods, an honestly acquired certification is an indication that the certifying person (1) has largely dealt with the subject of the project management methodology to be used, and (2) has mastered the terminology, i.e. S/he is able to react in the corresponding environment.
The costs of such certifications are in many cases not insignificant and are usually required by employers. This could be another reason why such a requirement for a certification is not necessarily compulsory for freelancers in any case. This is especially the case as there are following costs and recurring costs for recertification as well as for the application of qualifying training courses (e.g. PMI). Experienced and broadly based freelancers will hardly want to devote themselves to one methodology only, and wasting money there.
In the relevant certifications (PMI, Prince2, RUP), the skill sets beyond the pure PM methodology that a successful PM is required to have, are handled only marginally and indirectly
About the „real“ project management skills
What are the characteristics and skills that are obviously difficult to measure and therefore difficult to certify and which of these should a project manager, whether freelance or employed on the road, should have in his portfolio?
I am not taking the claim of completeness for me in the following, but I refer to my experience of the last years in the areas of software development, DevOps and infrastructure.
The initial analysis
To begin with, i.e. when entering a new project, the question is to ask the right questions in order to analyze the current situation and the planning based on it and, if necessary, correct it. This applies both to new projects as well as to projects already underway.
It can happen that a project that initially appears to be „green“ (which was sold as such at least in the interview) turns out to be red. The newly entered project manager must carry out such an analysis with the necessary assertiveness but also with the necessary flair.
- The entry into a project is the best time to immediately ask all the necessary questions. If this is missed or the new project manager behaves as a fellow traveler, the resistance to changes will be significantly higher at a later point in time.
- In other words, it is easier for a new project manager to implement the necessary changes right from the start when the hopes are still on him / her. Later, this is no longer the case – the project manager has already become part of the problem.
In the best case, this coincides with the incorporation of the PM when the project is actually in the specified state.
At the first signs that any projection result, e.g. a subsystem that is not in its official state, the actual status must be determined – then best for all components.
If a greater number of such deviations of the real from the officially becomes evident, the PM depends on the assistance of other project staff in the analysis of these deviations. Of course, this will, , slow down the progress of the project.
Especially in ambitious projects in which releases are rapidly being generated by customers, it happens that, despite an agile approach, there is a situation in which „suddenly“ the system components can no longer be integrated.
The reason for this could be the continuous accumulation of technical debts over the last iterations.
Especially in projects that aim to roll out releases at high frequency and bring them into production, the impetus of technical debts should be limited by agile procedures and techniques such as continuous integration and continuous delivery.
⇒Project teams deliberately accept technical debts; this is the long-standing practice. This may be because a necessary subsystem is planned for a further project phase. In this case, so-called mocks or scaffolds would have to be used, maybe without an already existing interface specification. The meaningfulness of such a planning is not subject to further discussion here.
In addition to technical debts, there is another form of legacy. I would like refer to this as „Hidden Backlog Items“ (HBIs).
HBIs are impurities and incompletions that developers consciously accept.
The motivation for HBIs is that the system or the application can be used „at the moment“ with the current incomplete implementation as long as certain use cases still to be implemented are not yet in place. Usually, programmers undertake to correct such a HDI – „soon“ or „when the time is there“.
The danger of HBIs is obvious:
- The processing of such HBIs is either forgotten as it is not stated officially or
- They artificially inflate the low cost of implementing future features.
In any case, HBIs have two consequences:
- Project planning is made impossible
- There is an unexpected lack of integration testing.
Of course, it might be obvious that HBIs should not appear in case of code reviews carried out with expert knowledge as well as well-defined and respected definitions of done. Proper code reviews could identify or prevent such HBIs at an early stage, if combined with professional expertise.
⇒It is the task of the project management to identify these HBIs, and, if possible, to assign them to the technical debts.
For those HBIs, which cannot be classified into the category of technical debts, e.g. known errors/defects or problems, these must of course be scheduled as well, with the corresponding priority.
In fact, in the context of a truly agile software development, no technical debts are expected in the larger frame – the same is valid for HBIs.
Of course, the question arises as to where from now on in the coming iteration(s), the time should come which is required to pay off the technical debt.
The required project management skills
It is certainly in the fewest cases an option to put the entire project on hold. Instead, the identified technical debts and HBIs must be planned into the project plan, which of course has consequences with respect to the deadlines or the commitments to the customer or „the business“.
This is why the project manager is required to show assertiveness as well as the necessary „flair“. For a PM, there is no benefit in insulting everyone by showing that it is all crap immediately after project initiation.
This ability is particularly important in an intercultural environment. According to the author’s experience, most of the IT projects to be undertaken are currently in the international arena, if not in a global environment. In intercultural constellations, the PM is often expected to have a senior and strong performance – in conjunction with the usual way of addressing problems indirectly in some cultures.
The term „transfer“ refers not only to the one-time transfer of the current project to a holiday representative or successor, but also to a periodically recurring transfer of the project by the PM… to himself. This requires the ability to dissociate from the PM.
Although some representatives of project management negate this, a technical understanding is very helpful in order to ask the right questions with the necessary vehemence to developers.
It is not a matter here that a PM shall overrule architects or programmers or to come with comfortable advice, but to get as realistic as possible the situation.
The two poles of project management
The regular work of the PM requires two properties which are contrary to one another:
Processor orientation and target orientation
I seems to be so simple: The PM has to carry out every step of the methodology required by the project in question.
This is a Sisyphus task par excellence, which the PM must carry out independently of the respective project situation, e.g. Status assessments, reviews, project planning and document management at the required level of detail require a high degree of self-organization and similar routine tasks.
⇒In terms of processor orientation, the conscientiousness of a „diligent ant“ is required.
The PM must always keep the official objectives in mind and keep them in his focus. Prioritizing as well as re-prioritizing and shield the project members of tasks and influences that oppose these tasks.
A PM must not be afraid to (re-) prioritize tasks and reject work results if this is necessary to speed up the achievement of project goals and milestones.
⇒ In terms of goal orientation, a certain degree of innovation and the ability to make decisions is required, as an entrepreneur has to show.
No PM is born as a PM – this may be a general statement, which may apply to many professions, for the role of the PM in particular: A PM must be able to act efficiently and effectively in the field of tension between process and target orientation.