tips and discussions - Henning Zeumer Projektmanagement

Life tells the best Stories

Actually it is easy to remedy projects in distress. Because the causes are usually as trivial as the resolutions for the Project Recovery.

The Classic

A project quarrels with the departments involved about resources. It needs skilled people with good knowledge on the topic, but the line needs these, too, and is not willing to dedicate them except (if at all) some who are on the bench anyway – a classic. In the end both are loosing because it will not work as planned that way. Sounds logical, doesn’t it? The solution: The departments do desire something from the project. So put them into the driver seat, make them “Product Owners”, take them into the responsibility !

Often the problems are at hand, but the customer is defending the resolution.

Burning Time - Project Recovery, Project Management

A project in Public Administration was about 6 weeks before it’s Go-live. That had been postponed several times already (total project duration 1 ½ years so far), and the budget was exceeded by far. Already at the first talks upfront in a video call I heard that project roles and responsibilities were not clear yet, the IT supplier did not deliver to whatever planning, and that the Go-live must happen now by any means. Well, I think I have an idea…

Ironically enough they played very budget sensible due to strict release processes etc., and they decided for a “cheaper” solution for the Project Recovery. If only it weren’t tax funds again, I wouldn’t have cared!

AllIn - Project Recovery, Project Management

Apropos budget – another example:

A big energy company planned a business critical project (I knew it would be a program for the Project Recovery) to implement very specific software. For that there are not too many project managers with an adequate experience available out there, but I had done that two times before successfully. However the daily rate budgeted for project management did fit for average skilled project managers without special knowhow, and they were not willing to “needlessly” increase the budget. At the moment of this decision they de facto increased the project budget needlessly and significantly…

Or the advised company does not see the point behind the proposed solutions. This is what happened after a revision of an SAP S/4HANA project that had already failed to see 3 planned go-lives in 3 1/2 years and had exceeded its planned budget by several million Euros. The audit revealed a total failure of the project management, also at the implementation service provider, because the customer refused to accept even the basic features of a structured approach (e.g. according to SAP Activate Best Practices). Project management would only have disrupted the daily routines, an added value of the “overhead” could not be conveyed.

That means I can’t rescue not every project or safeguard it from distress, in particular if I’m not allowed to. This category also applies to two more cases. Here however I had already some time to prepare recovery measures.

(Survival) critical measures cancelled due to resource bottlenecks

4 Bulbs - Project Recovery, Project Management

At the first one the management and a little group of engaged people compiled a huge catalogue of ideas how to establish our AfterSales with lots of customer benefits in a mature market to intensify this profitable business, and protect and increase market share. All were clear that this was, though technologically leading, without alternative to stay market relevant in a few years. I defined these ideas to initiatives and projects, and structured them sequenced and correlating as a program. Some of them we even started to execute.

Then some of the managing directors in some emerging markets considered that they were doing quite well as is, and that they had too few resources. Budgets were cut; the company was too “lean” to execute the projects. Project Recovery would mean here: You should sharpen the saw in summer to go to the woods before onset of winter, or you will have to leave chances at hand.

Being not able (or willing) to understand, and desiring too much in one chunk

In the second case we talked about a engineering company’s business unit running out of rudder (organizational as well as financial). They wanted to place new and future promising products in the market based on a few contracts with pilot customers. But R+D and customer projects went quite unsynchronized, followed by long delays on committed milestones, and the risk of high liquidate damages, cancelled series orders, and the loss of market advantages. We simply had too few resources for increasing (on top of the pilots) customer projects, and development projects did not keep pace – using the same resources – with their delivery. The cause-effect-mechanism is clear, isn’t it?!

So I started for Project Recovery as the business unit’s programme manager to establish structure, tools, and processes to control resources, interdependencies, joint risk, and communication between the involved parties and stakeholders – following the motto “to build a fence before catching the chickens”. Also we implemented some circles with my moderation to better coordinate the customer and R&D projects. Recruiting was getting up to speed, and for software development which repeatedly trashed our milestones I was planning project reviews.

Checkmate - Project Recovery, Project Management

Then my contract wasn’t renewed. The unit lead had not understood, what I did, what programme management meant, and what was necessary to do, rather was focused on the external picture towards the C-level than to the program’s content, and may be saw a competition in my activity which I could not dispel. Despite we already were completely overloaded, she accepted, while complaining the resource situation to the management, three more customer projects she “could not let go”, hoping she could generate nicer figures for the business unit. I cross my fingers for my colleagues…

Each consultation only can be as good as the consultee is allowing

Sometimes it just comes with too much transparency, uncomfortable truths and or unpleasant Must Dos – especially if things are that obvious and trivial. Life definitely writes the best stories to tell. But there are also the good examples without resistance to take advice and learn. And these are the cases that take companies and employees further without any feeling to throw good money after bad.

Learn more about Project Recovery…

Project Recovery: Throw good Money after Bad?

Why do project responsible people in management often boggle to have distressed projects recovered professionally? Because they don’t (want to) see their responsibility for the troubled project? Because they would need to to deny their own management mistakes? Because… ? These things are topics of many of my previous articles.

In very many cases they try to get off cheaply – mostly much too long – with pressure and the same so far successless means of their project management. In fact most of them shy away from taking again money in hand to effectively recover the project and protect the business benefit it was aimed for.

If you think to call external help for your project in distress would be too expensive, then just calculate your Business Case when continuing with your (insufficient) “materials on board”:

Extended resource blocking
Lost margin due to expensive re-work, discounts, concessions or penalties
Higher risk like failed project objectives and reduced benefits
Missing revenue or return on investment due to delayed time-to-market
Loss of trust, customers and image as well as bad references following
Employee demotivation and fluctuation etc.

To prevent or mitigate this – a project manager well experienced in project recovery is much more favorable every time. Call me – now !

Please also visit my corresponding Project Recovery offering

Digital Transformation – a Promise and a Mammoth Task

Improving the customer experience with digital solutions, increasing operational excellence by adapting to changing markets and digital transformation and automation of operational processes, improving administrative efficiency – a wonderful new world through digitalization.

This is THE opportunity for IT managers and CIOs to step out of the shadow of the board of directors and to no longer just be “enabler” but rather “driver” of the new business! After all, we digitize with modern IT technology, because our processes are supposed to be faster, more automated, more customer-friendly and cost-effective and are supposed to unleash additional potential – sometimes not explicitly even called for by business. But beware: of the last 5 projects that needed my help and refurbishment, 3 were digitalization and transformation projects. So it seems they do have their pitfalls…

Why many digitalization initiatives are getting into trouble

Complexity - digitalization, transformation, program management

First of all, it is probably the complexity of the dependencies in which such a change (= transformation) is taking place. It’s not just about digitizing individual areas or processes. With each building block you come across others which, if you do not include them immediately, will cause a breach of media or logic and thus threaten to undo the whole positive effect.

A holistic digitalization strategy must therefore be first and foremost. The development of a “Digital Ecosystem” includes both technical and organizational components. So first we have to analyze exactly how digitization is defined, which (specialist) areas will be affected, which processes and interfaces need to be considered, how is such a project or program with resources, knowhow (incl. Program Management !), and budget, etc. set up. Last but not least, this most important initiative of recent years will have to be measured by its contribution to the company’s goals as well as the corporate strategy resulting from it. This means the ball for the sponsorship role is in the court of the entire board and the CEO!

All beginnings are difficult – how to start?

Probably every company will start such a complex project with a lot of question marks and uncertainties. You can’t have everything pre-predicted on your Radar. You have to develop that from the rough ideas into the subtleties. An “agile” approach will be necessary to focus on the important things and to be flexible enough to react quickly and efficiently to mistakes or wrong developments before major losses arise. However, the complexity of the interfaces between the components to be developed requires, in my experience and conviction, a single, unifying “hybrid” program management that brings the individual threads together, coordinates them and at the same time keeps an eye on the maximum possible overall benefit.

Where are the problems?

There is no one-size-fits-all or “proven roadmap” for a digitalization programme. Every company is different, and thus every strategy and every implementation concept is unique. At this point, however, I would like to draw attention to the many pitfalls, hurdles, and limitations that I have experienced in my “healed” projects and programmes, and which any digitalization initiative will experience and how they overcome or resolve them will ultimately decide between success or failure:

Limits in corporate culture: Digitalization is present in many, if not almost all, areas of corporate organization, especially in “mature” companies. The Board of Directors and departments must relinquish responsibility and redefine their roles in the future digital world. This will not be done without friction.
Limitations in the organization of companies: It is not uncommon for the accents of the products and services to be redefined in this phase. A completely new, perhaps even project-driven business model is emerging. Digitalization is always associated with a ruthless revision and unification of workflows and processes, so that they can be streamlined, digitized and automated. Here, too, beloved habits and competences will be put to the test on a massive scale.
Limits in technical competencies: Digitalization comes with new operating concepts such as scalable, cloud-based and/or mobile solutions. They often come with in-memory technologies and big data (e.g. based on SAP S/4 HANA or similar), Unified Communications & Collaboration (UCC), a digital identity for every employee, digital work places and O365 for efficient access to information, etc. Are we already prepared for this and properly set up? Do we have the process and technical knowhow in our own ranks? Do we need external help – service providers for implementation, and experienced project and program managers on our site who can stick to the plan and avoid creep?
Limits in data quality and data management: The digital processing of large amounts of data will lead to the merciless disclosure of poorly maintained or incorrectly generated data. The effort required for data cleansing in legacy systems and the definition and planning of future data to be collected or generated should not be underestimated. And once you get a taste of it, you will want more!

How to make better progress

Lighthouse - digitalization, transformation, program management

The “natural limits” at the start of the digital transformation certainly seem gigantic at first, but they can be dealt with using caution and realism, but not under unrealistic time constraints. The initiative’s complexity requires competent Program Management for governance. And it must be clear that all this will cost a lot of money. However, the pay-offs of a sucessful transformation are at least as large. Last but not least, for most companies, their remaining in the market in the medium to long term will depend on it.

If you want to do it well, you should also consider:

Measures to secure the Digital Trust and data security. The new cloud and mobile components open points of attack.
A digital laboratory for building and testing prototypes. This includes a well-thought-out test strategy and concept, such as regressive, automated testing, as well as the capacity of one or more good test managers.
Digital Reverse Mentoring, a multiplier network, digitalization training, a Corporate Digital Committee to initiate company-wide digitalization initiatives, annual digitalization reports, a digital core team and digitalization partnerships. The transformation will bring a lot of corporate change. Neglecting this would greatly reduce, if not thwart, the main players in the game, who do onboard users sufficiently, thereby severely limiting, if not thwarting, the effectiveness and success of the investment.
Use Cases to AR/VR/MR, IoT, process digitalization, RPA, block chain, smart services, electronic access control and voice assistance including Proof of Concepts (PoCs) with Minimum Viable Products (MVPs), et.al. There is no limit to the entrepreneurial creativity of opportunities here, and in some innovation, there may also be an market advantage that should not be underestimated.

Result:

Digitalization is certainly not just a short term, modern hype, but a necessity for future competitiveness.

The digitalization initiative is not just a few digitalization projects, but a complex transformation program that is coordinated with the corporate strategy and strictly aligned with business benefit. Even done as agile.

You have to have the appropriate knowhow (process, technology, program management) in-house or at least on the side of the CIO at the conference table with external IT service providers, otherwise it can become expensive and ugly.

The reward is a self-organizing, sustainable and scalable digital ecosystem, a wide range of possible customer initiatives, up- and cross-selling, new customer orders, tried-and-tested use cases and smart services with improved customer experience and operational excellence. And last but not least, the ability to adapt more flexibly to changing markets – as a future perspective for the entire company.

For more information about the necessary Program Management, click here…

What makes a good Project Manager ?

I’m frequently asked how to uncover whether a candidate for a project lead position is capable of his „craftwork“, or not. Well, you only really know after having worked with him/her. But in the course of the many years in project management I think I have recognized a few “patterns” that at least can give a hint to his/her quality.

Self-organization and structuredness

You can probably lead a project well-structured and target-oriented only if you have a good self-organization and working structure yourself. An adequate stacker system to retrieve information in general and in addition specifically a reasonable project repository with a good overview for me are basic prerequisites to be and stay “on top” of a project, even if it’s getting a little bumpy sometimes.

Often a quick view on the candidate’s desktop is sufficient. Is it overcrowded with lots of unsorted icons/links, or organized, well-arranged following the most important work topics? Same applies to the Outlook Inbox. Is it tidy, processed and/or arranged in structured folders, or chaotic with many unread messages? At a glance you can see quite easy how someone is used to work…

Methodology and practice

Many application letters already contain some hints to the applicant’s level. To be clear right upfront: I know a lot of skilled project managers without any certificate, and also quite a bunch of certified “colleagues” without any clue of project management. At least certificates earned show a more or less profound education. Best Practices learned this way also offer the opportunity to apply some self-reflection to own (project) practice. Autodidacts on the other hand only had a chance of proper learning if they had good patterns…

Toolbox - Project Management, Project Manager, Project Lead

During the interview an interviewer knowledgeable in project management also learns whether the candidate has understood his method(s), and whether he applies them situatively, i.e. with a certain selection and without dogmatism. Evangelists only substitute the weaknesses of one approach with those of another.

And of course the candidate’s CV should show a track record of successful delivery in past projects, i.e. in time, in budget, and in expected quality. Otherwise you need to challenge that specifically.

People Skills

The so-called „weak“ factors are often underestimated concerning their criticality for success, especially if technical specialists are „promoted“ project leads. Actually it is one of project managements primary tasks to motivate the team members and facilitate collaboration. As team members usually like to execute their tasks as undisturbed as possible part of the leadership is to take care for few but well-structured (effective) meetings. If the candidate shows a tendency to micro-management (as often happens with project leads from the technical staff) he will probably soon let his job as a project manager slide. In distress he will probably bow out in favor of his technical expertise. Project Management then will tip over the egde. Good team players instead rely on self-responsibility, roles and delegation, and they consequently track results in a structured way.

Teamwork - Project Management, Project Manager, Project Lead

Not every candidate is equipped neither with a second, very important „weak ingredient“ which is leadership quality. A good project manager needs to have this towards team members as well as towards his deciders/superiors. The focus should be on good decisions that drive the project forward. Generally good project managers show a distinct Stakeholder and Change Management, and they have a straight talk !

At the interview I also watch out for eye contact, commitment and consequence, which are indicators for good leadership. To build a good team from average employees it also takes you to be very authentic showing and practicing yourself what you pray and request…

At the interview

Unfortunately I very often meet candidates at interviews who may have prepared themselves a bit about the company by the web site but are briefed only rarely or quite generally for the open position. In many cases that might relate to the screening process upfront and weak job profiles, e.g. via recruiters or procurement. This rather leads to the cheapest but not the best…

A candidate for a project manager position does not necessarily need to be a distinct subject matter expert (see above), but important is a certain affinity and interest to the project’s subject.

Opportunistic applicants or those who would like to prove themselves „with something new” I turn down on principle. Instead I honor the well-known virtues for potentials: motivation, curiosity, perspicacity, engagement and resoluteness.

A candidate with interest will strive to deepen his understanding of the project and the client’s expectations. I would always ask for details of project scope, and e.g. whether it is a Green Field or Brown Field project, an initial installation or a migration from legacy etc.

Spy Glass - Project Management, Project Manager, Project Lead

The project‘s setting, like company, industry, project status, suppliers, stakeholders, team size and structure, whether we have dedicated team members in the project, and whether they work co-located or virtually etc., is essential to get an impression and judgment of the challenge to overtake.

More candidate’s questions should clarify the report and escalation lines and his own competencies in the project. For example is it planned to have a double-head with a technical lead or a supplier’s project manager? And last but not least he should care for the modalities of his own ramp-up until he takes over the project responsibility.

Self-evidently the interviewers or dialogue partners should be sufficiently prepared themselves for these questions. And perhaps after this accurate job clarification you also should be open talk about the price once again. I find it unserious to give a binding pitch without a sufficient clarification upfront as often requested by recruiting agencies…

Profiling for preparation

To find the right project manager for a project obviously is no coincidence but needs to be well prepared. At project recoveries which I perform I use to overtake the search for a matching internal successor and apply the criteria mentioned above. But also for projects that are going to be set up new the checklist is helpful. In addition you can ask for professional support at project management staffing. How? Just have a look at https://pm-professionals.eu/?page_id=109 .

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

Project Management: Why Projects fail

In many of my articles I have tried to visualize the sources of bad projects: companies’ insufficient acknowledgement and consciousness for good project management ‘s value. Today I’d like to dedicate a little time to my experiences I encounter in my project recovery practice all over again.

Technics is overrated

There is a lot of research about issues and reasons why projects fail. To say it upfront: technical problems only cause a little fraction of it, not more than ca. 10%. However most of the responsible people in management and within the projects investigate first and with focus here. You can see this especially in engineering environments…

Four major root causes

The problems mostly are not of technical nature, rather than there are four main factors which repeatedly have led to project distresses according to my long project and project recovery experience:

the individual “project manager”,
insufficient project support from the company respectively the organization,
not enough time, for the project as well as for project management, and
the task itself, especially its complexity.

The respective statistics list factors like communication, resources / skills, unclear requirements etc. which overlap with my categorization, but are in my opinion the effects of the clusters I have chosen.

Weak project management is a result of weak management decisions

Individual - Project Management In one of my case studies (https://eobz.de/?p=1454) an “experienced” project engineer, an eminent authority in his profession, had been assigned project manager. He was taken up in his science, research and development, but didn’t find a good rapport to project management and team leadership. The “human” result: He invested the majority of his time and attention into the product while the project’s planning and coordination fell apart. When the project got distressed he focused on what he was best in – and again project management suffered.

If take managing your projects serious – and that should be the case at executives, similar to managing their business – then it should be clear that employees don’t automatically become good project managers just by having contributed to many projects. Best case they become as good as their examples, but they may also copy some bad practices.

You can learn good project management practices

Toolbox - Project Management If you want to lead a project successfully you need, similar as in other professions, a good, methodical education which includes recognizing the specific project situation’s requirements and reasonably applying the adequate tools and techniques situatively and virtuously. That’s at project management like with craftsmanship where you find trainees, advanced and masters.

Therefore a good project manager would not have undergone flaws like in our case because he would have taken care for a clear target and task definition from the start, and would have requested his superiors’ support consequently – for the sake of his project and himself. His planning would have based on realistic assumptions, and he would have identified and escalated risks and deviations and initiated counter measures early.

Project management is a leader position

Seal - Project Management To achieve he also needs another skill: leadership qualities. He is his project’s manager, responsible for the result, and he must steer his team and his superiors so that each one contributes his part to the whole. Not an easy task, in particular if the company doesn’t work project affine. And not everybody is the person for a leadership role, feels well in it. But if he takes his job serious he will apply project management including leadership consequently. Otherwise he will soon become a scape goat if the project fails. Not a very motivating perspective, or a subject for opportunistic PM nomads who sometimes call themselves project managers…

Have time for project management

Time - Project Management Another frequent factor for troubled projects is time. I don’t mean the duration granted to the project for execution. This actually should always be sized realistic, not determined by wish thinking or arbitrarily. That means it must be based on realistic estimates done by the executing team members and taking the interdependences and frame conditions into account. Therefore “duration” falls into the category “Individual” for me, i.e. that the project manager does a competent job.

I’d rather reflect the time granted for project management. If you look at many project budgets this position often appears calculated significantly too narrow or even not at all. As if you could do this job with cheap resources or just at the side – that’s how expensive projects arise !

pmquota - Project Management In fact many statistics, e.g. the one at https://eobz.de/?p=854, show that may project managers spend only a fraction of their working time actually with project management. The majority is dedicated to activities like business development, technical execution, functional line tasks etc. The reason mostly is the way the company “does” project management, but also often the project manager’s self-conception as described above in “Individual”. But if everything else is more important than project management you don’t need to complain about miserable project performance.

Have time for the project

The time for project management can obviously be scarce for the project manager because he must take care of multiple projects in parallel. That’s probably even the usual case in small and midsized company. It may be acceptable if the projects are in various phases with different needs for attention and communication. But in general – this is proven by many studies – multitasking is very inefficient because of the permanent need for getting-again-into-the subject. Thus it costs more time, money and risk than concentrated work in only one project.

The more people work together in a team, the higher is the communications and coordination effort even in a single project if it is supposed to run effectively and efficiently, and project management is a full-time job. Then it is reasonable to bolster up in staff with the advent of many projects, be it with own well educated project managers of with externals. Because the better or less the project manager can take care of his projects the better or worse it will go. Simple logic, isn’t it?

But that’s the point where we already are at the projects’ integration into the corporate organization by the management, the hot spot why projects fail which I will regard more in detail next.

Competing projects and lines

Did you know? More than half of the issues in troubled projects are not caused by sources inside the project itself ! That’s why you can only cure the symptoms there and recover, but at the next occasion problems will re-occur.

Classic example: The project manager is requesting resources for his project, but he does not get enough and not the ones he needs skill wise but those who are on the bench. These are often not the best as those are needed for line tasks obviously. And if there is a lot to do at the lines even these resources will be re-prioritized…

Organization - Project Management So the predominant part of project issues arises out of an insufficient support from the executing organization, which in turn is founded in the project culture, the management’s and established organization’s mindset.

Where departments or plants are responsible for P&L, projects always be in the second lane. What a pity if the company even makes it’s money with projects as in IT, consulting, machine and plant engineering etc. Then the business units may be quite profitable, but not the customer projects. I’ve seen top quality being delivered that way so often, but unfortunately not at the agreed upon milestone or within the calculated budget.

Insufficient Project Management organization and infrastructure

No project can perform decently if it permanently faces resource issues, if collaboration and communication within the team, between team and organization, and among the department silos doesn’t work out because it is unfamiliar, or if the project manager’s authority doesn’t fit to his responsibilities.

In many companies in addition well attuned, fast interlocking procedures for decisions, escalations, risk and change control etc. are missing. Sometimes there is not even a sufficient infrastructure for projects in place, e.g. standards, processes, and tools. Being all alone on his own the project manager is like Don Quixote, and the “work floor” team members’ motivation for engagement in project work as well as the project’s results are unsatisfactory accordingly.

Do the home work !

Before holding the crisis project manager the scape goat at the management executives should do their very own home work and critically investigate whether the company’s projects find the frame conditions to prosper and be successful. In case the business model is even project driven further reflections (see https://eobz.de/?p=2142) might bear enormous surplus strategic potential.

Trouble cause task

Usually the endeavour is weighted heavy as being the source of problems in projects. How that applies to technical challenges I already described at the beginning of this article. But many times there are very different aspects of project work that make projects fail. Task - Project Management

Dependence due to lacking internal know how

Let’s think about projects of which the subject is beyond the company’s core competence, e.g. an IT project in a producing company. Then in many cases there is only limited internal know how with the project’s IT solution but also with experience in handling the external supplier or consultancy. Project management is purchased together with the trade, and so you get at the mercy of the supplier all too often – if you do not have a good project manager at your side as a counterbalance.

The endeavour’s complexity

Or let’s talk about the project’s own complexity instead about technical green field challenges. There are a multitude of interfaces between the departments (cue cross-functional work), suppliers and sub-suppliers, all with an own understanding of project work, different organizational maturity and eventually reliability. But any case with high requirements towards complexity - Project Management communication and coordination.

May be there are also dependencies from or with other projects. In international projects this possible source of issues will potentiate with distributed and/or virtual teams, cultural differences, and work across time zones.

And then there also some more and sometimes prominent examples where complexity is driven up to absurdness by politics, interests and influencing…

Project success lies in management’s hand

As I already said: There are a lot of parameters which, badly managed, may quickly lead to failing projects because they are underestimated by managers responsible for the project, and staffed cheap but underqualified or even not at all at important positions. Last but not least – but not exclusively – it is the matter of the deciders on management level, how they anticipate and acknowledge the role projects play in their company, and how they define the rules according to which corporate projects are set up, staffed, executed, and supported. It’s a good example of how corporate success is really determined by the management.