PM excellence - Henning Zeumer Projektmanagement

Kanban Board and Project planning

A Kanban Board is an effective tool to self-organized control “work in progress” in small and mid-sized initiatives by the team. Everybody directly sees the tasks to do, the ones in progress or done. You only need a bit of discipline to have everyone place his task appropriately to progress on the board, but that’s not all too much, and the advantages for the team work are obvious.

Project management is needed when the amount of tasks gets bigger, when someone is required to keep oversight, to draw up the tasks on the Kanban Board and coordinate their execution. Or if there are multiple teams with individual Kanban Boards where the deliverables need to be put together at certain points. It is the (well-versed) project lead’s decision to apply a classical planning and agile execution in a hybrid way or control with a „Scrum of Scrums“ – according to his preferred project approach.

Read more Lessons Learned…

Avoid multitasking

Management is only really necessary if you need to make multitasking possible, e.g. to level or optimize workload. You can reduce management effort e.g. by simply planning more time (buffer) to execute a task. Find out the point in holistic optimization where downsizing management by increasing duration is not overdriven by more management effort for too much multitasking !

Try to avoid multitasking, to keep to a task and finish it instead. Put in lock waits where you are not disturbed. That saves time and energy as you don’t have to immerse in the task over and over again.

Read more Lessons Learned…

Unbeloved meetings, but necessary

Meetings are time eaters, but often necessary to get a bunch of people on same information level and/or receive decisions.

Daily team meetings, so called “Stand-ups”, are helpful to coordinate the just completed tasks and the ones ahead. If held standing (so that nobody may lean back comfortably) and lasting no longer than 15 minutes efficiency and (self) discipline increases.

Weekly or bi-weekly “Jour Fixes” serve well for organizing the project and should be conducted with a regular agenda. If decisions are required the deciders should participate – this accelerates the decision making and saves additional meetings.

By the way: If the colleagues often miss meetings or decline short-term because of other things, they maybe judge the you or the meeting not to be that important. You should follow up, perhaps cancel the meeting completely and change to other communication channels.

Read more Lessons Learned…

Success factor Communication

Good communication is key to successful projects, bad one the most frequent cause for project distress. The more communication is direct, the more it is effective. That’s why:

face to face talk
                        => over video meeting
                                               => over telephone call
                                                                       => over email !

Particularly written communication often leads to misunderstanding and/or many inefficient coordination loops. Therefore: encourage your team members from time to time to stand up from their desks and visit their colleagues in the office on the opposite side of the floor…

Read more Lessons Learned…

Timeliness is a virtue

Sometimes it’s just (bad) habits that influence our effectivity or efficiency. For example timeliness at meetings:

Are your colleagues always late at meetings? Just make the appointment at 9:28 or 9:33 instead of half past nine. You will achieve a completely different attention to your invitation. You will see !
If people are failing to attend the meeting on time, start anyway and don’t repeat anything to accommodate the latecomers. It sometimes takes a little, but if you are consequent the nurturing will soon succeed…
Starting punctually implies finishing on time, otherwise you aren’t consequent ant get inauthentic. Provided you have planned and lead your meeting well, and all participants are well prepared, that should work. If one time it doesn’t match finish the topic and postpone the rest. Successor appointments and the colleagues’ planning depend on your timeliness, too !

Again Timeliness: There is few things more annoying for meeting a plan than an unexpected late delivery. However at most times the provider is able to foresee that he will not be done in time. Strongly advise the colleagues to give notice of a possible delay as soon as possible to give you the chance to re-plan reasonably and thus minimize the impact.

Read more Lessons Learned…

Project Management – The long Way to Agility

It already improved a lot. Not long ago agile evangelists and classic Project Management and its project managers unconciliably faced each other: Agile as the new and only truth to execute projects was hip and we had it absolutely outdated with the pre-planned waterfall. Therefore a lot of companies proclaimed the hype “we’re agile now”, too, and by majority badly fell flat on their faces. I’d like to analyze this a bit today and promote a middle course.

You aren’t agile by acclamation. It’s a mindset that differs so much from the so-far usual corporation paradigm of hierarchies, planning and control that it must be at least hard to digest for such “evolved” companies at first sight. If you consider all the beloved “principalities” and directives comfort zones: It takes a long, sensible transformation, starting at the top and middle management down to the projects, to enforce and execute the culture change towards participative, collective and self-organized action.

Case Study Revision of a „classical“ Project

In my today’s example we dive into a typical German corporation which started to describe, standardize, and with the help of IT digitalize its core processes from acquisition over order management and execution to invoicing and dunning. For this, as always, they requested the IT department to implement, and afterwards concentrated on daily business again at the business. After a half year with traditional Project Management in IT the pilot was proudly presented at a branch. Both business and IT were disappointed by the reaction of the other side. More than a year followed in painful rework until the product was halfway usable, cost and time-to-market ran away. The board pulled the emergency break.

Active Business Involvement

My first suggestion to refloat was to have the professional departments actively participate, to put them into the driver’s seat. That looks quite unusual (!?!) in many “IT projects”, as first of all the business obviously has no time for “such things” and second it mostly has no experience how to do it. That’s how it was in our case, too: Nil report at requirements and project management – therefore: implement basics and call for dedicated project members at the professional departments. The IT management leaned back and waited for our falling flat on our faces. Instead in a relative short time we had a small, very engaged outfit together who for the first time agitated on the processes which should be mapped by the IT.

At the same time I looked around in the company and discovered some more projects at other departments that were concerned about just similar things and had requested resources at the IT for it. The board immediately realized the saving potential and synergies. First there was resistance at the “principalities” against the consolidations now following. I taught my team members a little introduction into Organizational Change Management and got some people from the other departments into our boat.

What does this have to do with Agile so far? Well, one key prerequisite for all agile approaches is an intensive, active involvement of the business side, who actually has to provide the Product Owners. And these guys need to know how the results should look like, respectively what the Definition of Done in reviews and tests should be. “Classical” Requirements Management as used with our process definition may not originally fit into the agile picture, but we did work very iteratively here with all participants, and we also used many elements from Design Thinking.

And this also shows that for companies which do not holistic „tick“ agile yet a hybrid approach may be more expedient than one „by the books“. To judge this competently and adequately decide to the situation is a good project manager’s task and skill in the end – who basically appears to be also not existent in the agile world.

Requirements: “classical” Investigation on Features and User Stories

With the help of a small consultancy which supported us at the requirements and process documentation we progressed well in all areas. lo and behold: Many of the departments’ processes overlapped or were even more or less the same ! From these 80% we could create a single end-to-end workflow with only very few task-individual loops in the end by a little abstraction and concentration on the essentials. A significant saving for the development effort to come, and a major volume of synergies from process optimization and standardization for the company !

Rough Estimation instead of definitive Budgets saves Time

A second, frequent impediment to execute projects really agile derives from the client management’s insisting in “classical” reporting fom Project Management: When will we deliver what at which cost, what is the actual status measured by progress to plan etc.? In our case that was accentuated by my second suggestion: We didn’t request a definitive cost estimation from IT but one of the accuracy of a „Rough Order of Magnitude“ based on the process documentation and the system components involved. Attention, now it becomes agile again: This way we wanted to avoid a lengthy, detailed requirements specification, and instead start with the development fast with backlog priorities coordinated in business and with the IT on the technical side.

The cri de coeur was loud at first. The board became worried by the big numbers in a cost corridor of +/- 50%, but finally agreed to a capped budget determined by a 3-point estimation. Much more struggle was with the IT management to let themselves in for such a cost estimation, without any requirements and specs and accurate calculation (which wouldn’t have been met anyway).

We lost much time until we finally received our ROoM cost proposal for budget approval after massive directive from the board. Maybe it helped a little that we accepted the ERP system’s configuration, being the entire topology’s basis component, as a compromise in a “classical” Project Management approach. But at the end this sub-project didn’t get along with the planned time, and even slightly knocked off the upper budget corridor bar which we allowed despite the “accurate” cost estimate…

Joint Development: collective Issues and Acceptance

We approached the left-over non-ERP components in an iterative-incremental way. But also here it took weeks to carry conviction to the IT not to insist to write detailed requirement documentation upfront. We had features and user stories that moved hand over hand along the process steps. How they should look like in detail we wanted to jointly, business and IT, define iteratively, and develop and implement ready to run. For the business side this was all new anyway, and they now were able to play their part in building “their baby”. Acceptance was high, and also at the buyers in management.

The systems engineers and developers at IT also liked the approach as they always had a person to talk to at the business for questions and coordination. And documentation should be done not before development was done and it was clear how it was done. Only IT management did hard with the loss of Project Management control especially over resource planning and the transparency with progress and issues.

For the business side the biggest challenge was to always have enough inwrought and coordinated people at hand, who ideally came from practice life in all colors but still had the ability to abstract and judge the defined processes from their own customs.

Success creates Trust and Motivation

The board already became impatient by the lack of visible progress. But behind the scenes we build up trust and confidence with every meeting of business and IT people, got the sand out of the gear box, became a joint development team, and finally achieved to get the IT management into our boat by open and honest communication.

And it started to make fun to jointly create something that worked well as expected, resolve problems, see success and finally also be able to show it to the Steering Committee. The overarching coordination of the many development streams I planned in a “classical” way, and monitored and reported it with the Earned Value method. Same I applied to the incremental rollouts to the business and the branches. That was soothing the board’s nerves…

Conclusion: Agile is Change and needs Time

The hybrid project approach took a little longer in the agile parts until it “came to fly”. That was mainly because of the resistances against loss of control without a “proper” planning, and the fear of too much transparency, but also because of the professional side’s simplemindedness for the “neccessities” of Project Management and in project work (in particular requirements and change management) and leadership in the beginning.

Our agile practices showed to be at least as effective as the ERP sub-project performed in a „classical“ manner, but much more efficient though certainly with room for improvement. By more practicing we continue to get better, the visible and quick success works as a motivator and convinces more and more stakeholders in the company up to the board. But however it remains a long way until all will work agile, and until the Steering Committee and the board will understand “Agile” completely.

Agile is not a universal remedy, and from my personal experience I can confirm that it is also not perfectly or exclusively fit for every company and every project. But it at least helps, applied in hybrid projects at the right points, to be more efficient and flexible. A classical Project Management will always have its raison d’être – in the hands of project managers who know their craft. Maybe then the title “The long Way to more Agility” is more appropriate.

Recently in Project: Earned Value Management

It is one of the favourite subjects in every PMI exam, since its introduction in the 1960s by the DoD it is mandatory for all projects with US authorities, in nearly each large company there is a Project Management software in use that is also fit to handle it: the Earned Value Management technique (EVM). The “superb” benefits of the integrated view on project cost, schedule, and performance is all but undisputed. However, many project managers are afraid of the assumed high effort of implementation and maintenance.

Earned Value 1 - Project Management Today I’d like to tell you about two examples that show why Earned Value Management is not as popular as it should in projects here in Germany, and how, in these cases, reservations have been overcome and implementation was completed successfully. I’d first like to mention that I’m a “fan” of this method, just because it is universal and uncomplicated to use, and because it provides a valid status determination as well as forecasts for Project Management with a few simple formulas.

Why Earned Value Management often is not used

Let’s start with the general obstacles I’ve regularly found in many projects:

Ignorance: Though every CAPM or PMP learned the formulas by heart, in most cases understanding to use them as a Best Practice with their Project Management is missing. Even if adequate tools are available their use is considered unnecessary overhead. This reminds me of company leaders who manage accounting balance sheet for the tax authorities, but do not realize what they could learn from them…
Ignorance: The Earned Value Management related capabilities of available tools are often unknown or inadequately explored before deciding not to use them. No doubt these sophisticated special applications have a lot of features, but I don’t use all the features of my spread sheet or word processing software either…
Ignorance: Not every company has a Project Management super-application in place, but very few project managers know how to use even MS Project or a simple Excel worksheet to implement a quite efficient Earned Value Management. They would rather a continue cutting wood with a dull saw then to just sharpen the saw once…
Ignorance: Even if an Earned Value Management approach is chosen for a project, the project manager often has to condense his findings to the simple stop light colours (RAG) because management wouldn’t understand his Earned Value Management KPIs. Management shrugging off responsibility and a lack of effective buy-in is has been proven to be the second most critical cause of troubled projects…

The list can be continued, but the root cause can be tackled easily and cheaply with a little training. Once they get a taste of it, a type of self-dynamic is developed which, if not lost again in routine and stress, delivers impressive results. This can be seen in the following two field studies.

Cases of successful Earned Value Management implementation

In the first case study I was called to a troubled project, status and future unknown. As in former days when practicing for the exam my team collected all data and facts, and supplemented with a reliable 3-point estimation of the remaining work. Each Earned Value 2 - Project Management single work package and case was assessed. We quickly managed to calculate the aggregated Earned Value Management KPIs for the third and fourth WBS level, thus being able to give a verified overall status, a profound preview, and a first detailed analysis of the main issue areas. From there on, a daily progress tracking, a forecast of when the SLAs will be met, and a detailed resource requirement determination was possible for all open cases. Project risk became calculable, and substantial decisions were enabled.

The second case was at a big company with a sophisticated Project Management infrastructure. The executives demanded that all projects were to be reported and all key figures aggregated centrally. During the year prior to my involvement in the project, they sporadically supplied a data cemetery within the headquarters with information, but with no feedback to the projects, while at ground level people helped themselves with their tools of the trade.

Revisiting the reporting within the project and to the headquarters resulted in the initiation of data aggregation streamlining, the elimination of many project internal Excels sheets and their replacement with structured and evidence-loaded evaluations from the central system. Only the smart determination of the granularity level for Earned Value Management reduced the unloved overhead by more than 20%. More synergies derived from less and shorter teleconferences (fewer things to clarify) and less redundancy in decentral controlling instances… leaving more time for the essentials !

Earned Value Management in agile environment

Some may say Earned Value Management is only fit for classic project controlling but not for agile development, where other methods for measuring progress and performance like Burn-down or Development Speed apply. But because at most projects I actually do not find a pure agile working “by the book”, and additionally management and Steering Committee rather “tick” classical, I like to merge the advantages of both approaches (see also my article “How Project Management and Agile together create increased Benefit”), though that might cause a little “translation work”.

In this case agile developments happens in a frame of a superior, classical planning (instead of a Scrum-of-Scrums). But a work package remains a work package though called “Backlog Item” in Agile. And therefore I can also analyze work packages handled agile with the Earned Value Management.

Actually I have a time box for each Backlog Item (e.g. count of sprints agreed for all of the Backlog Item’s User Stories), and the related cost, estimated with agile-fit methods, at hand. Just like in classical project management I can distribute these on the Earned Value Management’s time axis – the Planned Value (PV) is done. The Actual Cost (AC) I receive as usual from hours reporting and invoices.

Only the Earned Value (EV) requires a little thinking as I need the degree of completion to calculate it. In Agile using a classical phase scheme is not feasible of course. With short-time Backlog Items it is suggested to use the 0%-50%-100% method: open – in progress – done. With larger Backlog Items the “Themes” method from Feature-driven Development has shown to be effective: The item comprises many User Stories, of which the complexity is rated in „Story Points“ from 1 to 3 or 5 Points or per Planning Poker in the Planning Meeting. Stories completed receive a credit of their Points, and these cumulated in relation to the Backlog Item’s total count of Points reflects the completion status for the EV.

No epilogue this time – I assume the examples provide plenty incentives for reflections and tries …

Why Managers should revisit their Understanding of Projects to receive better Projects

Sometimes it takes a little longer to discover a relation. That’s why I like to store this article with my personal Lessons Learned. Already in a very early posting I asked my readers why it is so difficult to “sell” good project management to Executives. One reason might be that people – managers, too – actually understand different things with the terms “project” and “project management” dependent on their so far career path. On the other hand, that’s also why so many call themselves “project manager” without ever having managed a real project.

Examples to understand projects’ nature

The following examples should help managers and project leads to better understand their project’s “nature”, and thus take a more target leading approach for their project management.

Example Automotive: At the big automobile manufacturers a car model (e.g. the VW Bus) often is called a “program”, its sequential model series (T1, T2, …, T6) then are “projects”, which actually run until the type is substituted by the next one. This is in contradiction to the “official” project management definition and DIN/ISO 21505, where a project’s characteristics are having a defined start and finish, and during this time developing something new and unique (product or service). That’ when the project is done. The term “project” doesn’t include serial production. But this doesn’t keep their suppliers neither from adapting their OEMs’ point of view when developing and serially producing their components.

Another example is manufacturing by order, where components, accessories or the packaging are developed to the customer’s specifications, and then are produced in bulk. For these “projects” mostly proven process models exist, which exactly describe the distinct project steps in their sequence and content, and by which “forgetting” important work steps is prevented. Serial production is out of a project’s scope here, too.

What is it now, a project !?

The, following the above-mentioned project definition, characteristically innovative part of the project here is reduced to the tasks that adapt the product to the specifics of the new type or customer product. The project definition does not even foresee an ongoing production; which is rather reserved for program components or operations. In the examples above however, the product’s serial application or production usually is the main part of the “project”.

To make it clear: The guy widely known from do-it-yourself advertisements who, with the help of his DIY market, “does his project” truly conducts a real project according to the definition. He has reserved the weekend for it, he plans his activities and materials, he executes the tasks, and in the end he has achieved his “product” – new, unique, period.

How mistaken project understanding drives many Executives to not assign true project managers

Back to our industry examples: “Miss-used” that way such “projects” mostly get a kind of functionally focused “project management”. This means it is usually a very experienced engineer who knows the approach, work steps, tools, materials, suppliers etc. well, and primarily controls the execution.

Complexity - Project Management, Project Manager, Project There is very few focus on skills or an education in what I understand with project management, i.e. professional handling of uncertainty, risk, changing scope, schedule and cost planning, team building, team and supplier coordination, communication, leadership etc., actually planning and controlling the project. It seems to be not critical or necessary in this kind of fairly controlled environment, or it is thought to be easily done “at the side”. In many companies there is a technical lead responsible for this kind of work, and the project managers often care for many projects in parallel.

It is an even ignorant project understanding what I unfortunately not rarely happen to meet at the C-level as well: “We hire someone for X amount of money and assign him to some projects. For that salary he should probably be able to manage them!” I wonder whether selection and expectations towards managing the company is the same when hiring a General Manager…?

That’s why delays and cost increase are rather referred to technical issues instead of possibly insufficient management of the project with lacking overview, control and leadership. And therefore the Executives of these companies don’t realize how they would benefit from such skills at their project managers or from “true” project management on top of simple “execution” by the technical project leads (meaning double heads) in terms of project cost savings, time-to-market and ROI.

Not an issue in single industries!

Even in companies whose core business actually is „definition compliant“ projects recognizing this is not really common: In consulting, software development, machine and plant engineering or even in R&D V-Model - Project Management, Project Manager, Project creative activities are necessary besides technical work. Therefore the presence of uncertainty and risk is incomparably higher, exchange of ideas, team communication and collaboration are critical success factors.

Unfortunately also in these industries process models (e.g. Sure Step and ValueSAP/Solution Manager) or Standards (e.g. V-Model, PRINCE2 and ITIL) lead to believe being in controlled environment. These tools and guidelines provide good and precious support, but do not substitute their proficient use with a sound understanding of the application area project management by a method savvy project manager. Because what’s the use of it for me if my project manager has followed Sure Step exactly but nevertheless has failed to keep his schedule and budget?!!!

Also relevant in agile projects

Hoping to get better projects finally, some managers proclaim the change to Agile. Only few of them are conscious of what agility means for the company and thus for the management level, i.e. the working agile in projects doesn’t substitute a expedient project understanding, and that it additionally premises immersing in and embarking on agile methodology. To let the project team organize itself with some Scrum artefacts, but then expecting a planning and reports with fixed milestones, deliverables, and budgets, this will fail in agile projects, too. Where projects are done agile also the management must be wired agile. Without a correct project understanding, and knowledge and mastering of the project methodology every project is doomed to become distressed!

That’s why there always must be someone who “full-time” keeps oversight, holds the reins, controls and leads the team: a project manager, who owns just these skills, and preferably has learned and trained them methodically. Functional knowhow should be secondary in this leader role and reserved for the specialists in the team.

Why professional PM is so important just now

Let’s conclude: It is an “incomplete“ project understanding and/or a felt security of tools which often lead Executives to underestimate the project management task and assign it to improper hands. This has serious effects, namely that still the majority of projects do not reach their objectives concerning time, cost and scope within plan or not at all globally, and that many returns are burned or investments are written off. To judge this phenomenon as being “completely normal with projects” may be self-excused at politicians, but should bring General Managers, Vice Presidents and members of the supervisory board to the scene !

Burning Money - Project Management, Project Manager, Project But what no statistics can show yet is the effects persistence of this misjudgment and denial will have in connection with the actual fast progressing digitalization and the related sweeping change in the market. Because projects are made to realize change by definition – and that should be approached professionally and responsibly!

Learn more about projects and proper Project Management…

Wikipedia: Definition of Project Management