tips and discussions - Henning Zeumer Projektmanagement

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.

Read comprehensively more about this topic in my Book…

Project Organization – the Third Dimension of the Matrix

He would have never asked me for advice because I’m just knowledgeable about project management. At a lunch among good acquaintances he told me about his business, that all plants were achieving black figures due to good controlling and Sales was acquiring good contracts, but the EBIT was not really going to start flying. During our conversation he developed an understanding that his company wasn’t earning its profit with its products but with their commission and delivery to its customers – in projects.

The organization no longer fits to its market

This was exactly the point. The company had been established product oriented with a functional line organization. As the market was growing internationally it had implemented a matrix a few years ago with a sales organization clustered by regions. Now it was time to adapt customer oriented to the project-driven business because they often lost a lot of the profit generated in the functional matrix. In essence the customer projects needed to become more profitable to increase the entire company’s bottom line.

Business Administration thinks too egocentric

To approach the issue we need to look back a little into the past of Business Administration. Line and matrix come from a product oriented, egocentric view to the market. Until the 1990s the market thankfully absorbed the economy’s products and services. By technical leadership sometimes monopolistic or oligopolistic structures arose at the offering side in which the customers were quite dependent from their suppliers due to missing alternatives. Business Administration therefore focused, following the economic principle, on describing, analyzing and optimizing production and the organization of the running business, and developed management models accordingly.

Since globalization increased traditional market leaderships are questioned from the millennium on latest. International competition, cheaper and/or simple, but sufficient product alternatives from emerging countries with lower production cost as well as transparency of prices and services available through modern communication etc. have challenged the dominance of our companies in many industries. In addition there is an increasing customer emancipation fostered by the new competition situation on the offering side. The change from vendor to customer market demands for more flexibility at the producers, and also for keeping selling proposals in order to not suffering from claims, deductions, re-work and margin losses.

Established management approaches and systems are insufficient

This kind of change has not been re-enacted by many companies (like my acquaintance’s one) but also modern Business Administration sufficiently. Established management approaches and systems made for repeating processes and widely known influence factors are not tailored to the management of (customer) projects or unfit for with every contract changing or even unknown frame conditions. Often there isn’t even awareness for this difference in characteristics and imperatives of running and project business. Leading projects from out of the functional line reasonably therefore mostly fails because of the line managers’ time and goal conflicts as well as of the resource conflicts between line and projects resulting.

Established structures are overwhelmed

A project-driven business model (see definition in my article “Does Your organizational Structure still fit Your Business?“) demands for an organization structure and culture that concedes the same priority to the project earning the company‘s revenue as to the product built and delivered by the project. Global optimization must be the management’s focus instead of local KPI optimization at plants or departments with successes spoiled in unprofessional projects. It seems reasonable to also assign P&L responsibility and far reaching competences to the projects being the bracket from bid to acceptance.

The existing line or matrix does not achieve the cross-departmental function in most cases due to conflicts of responsibilities and competences. But projects need leadership across departmental borders on contract and project level as well as in the company management. Actually there also is currently a more functional and “classic” business competence at the department leadership level rather than extensive project management skills.

Adapt the company to the business model

Matrix 3dim_E There is only help in a transformation of the organization and corporate culture concerning established hierarchies, responsibilities, compensations, thinking and priorities etc. towards an organization focused on the project business. In a pure line organization this means the change to a matrix “function vs. project”. At an already matrix-organized company it will be the implementation of a third dimension on peer-level to the existing ones. What it takes and what to pay attention to I have described in my article “Turn-around for Enterprises with project-driven Business“.

This needs to be accompanied by building internal project management competence and an own career path in the new dimension. As project management is “management under heavy-duty conditions” it is also a perfect opportunity for leadership development within the company. Universal management skills like stress resistance and risk sensibility, methodologic knowhow, structured approach, social competence and leadership qualities are nurtured. Therefore the Third Dimension should be attractive for motivated employees to leave the functional line’s bosom with their company-specific expertise, join project management, and there win acceptance for the department soon.

We shouldn’t fail to recognize that this transformation will afford some mid to long-term effort, and will come across many fears and resistance in the established organization. Siemens Chairman Peter Löscher illustratively described this 2010 with his „bed of clay“ comparison. The colleagues in the projects urgently need it for the quality and success of their work, the top management wants to enforce it as acknowledged being critical to survive, and the middle management needs to comply – or leave. That’s what I finally suggested to my acquaintance for his company.

How Project Management and Agile together create increased Benefit

Once upon a time before the rise of the millennium, when the word Scrum wasn’t invented and the Agile Manifesto wasn’t written yet… Maybe then my today’s practice retrospective isn’t completely correct in saying “it recently happened”, but I had similar project situations over and over again in the recent years where the case of hybrid Project Management told here is exemplary for.

Near to the standard but completely individual – is that feasible?

The case is about a pilot project for an ERP template which should be rolled out to all subsidiaries of a worldwide operating company subsequently in follow-up projects. To minimize the cost the template should keep near to the standard application, but yet it should also adapt market specifics, tax and legal requirements at the subsidiaries as best as possible. Squaring the circle?

So it turned out to be as to be expected: The Statement of Work (SOW) was frequently adapted to change requests for new or changed requirements from the branches, the headquarter departments took this as an invitation to generously insert their special wish list, too, and the forecasted cost blew all budget limits. Thus the project did what pilots always do when they do not receive a landing permission: it looped.

Agile and “classic” project management form a symbiosis

Sprint Olanning - Project Management, agile

To get the project out of its requirements analysis and planning phase towards realization we decided to proceed iteratively starting with the core functionalities of the standard product. We agreed on a strategy to have complete and tested template ready to use within a certain span of time. This should be complemented and enhanced by prioritized increments subsequently until either the time and budget frame was spent or the template had sufficiently met the customer expectations.

Accordingly our “classic” project planning contained framed time and budget boxes, so called “control accounts”, which the management could use at all times for reliable forecasts to have safe a calculation and planning. We even were able to forecast quite precisely by the priorities when we would be able to submit what functionalities to the business lines for testing, judgement and approval, which in return gave us stability and confidence in development and well-disposed stakeholders for the project.

The achievement: Quick Wins, flexibility and safety

That way we got two achievements: First we could start development without further delays, i.e. without having to wait for extensive detail planning as the standard and the unquestioned basic functionalities in the first development phases (sprints) were already clear and fixed from the beginning. Within five months we had a basic release ready to deploy which covered 70% of the processes and could serve to design the mappings for data migration from the legacy systems.

Second with this approach we kept the “quarrel of requirements” from the team to have it work undisturbed. Since then the discussion was done between the (called today) product owners from the branches and functional departments who needed to agree on a prioritized list of requirements (stories) and define a minimal SOW (product backlog). Later we found that we easily could develop individual market specific enhancements in “country backlogs” around a common core (the template backlog), of which the incremental release was dependent on a proper integration with the core.

Top efficient: agile on development level, “classic” on project management level

During the entire development phase the teams were only bound to what they committed to deliver “ready to deploy” within the 4-6 weeks release cycles from the top-down estimated and prioritized backlog pile. That worked well in 90% of the cases. Development was planned into traditional Project Management master schedule and budget as control accounts, risk and issue management closely cooperated with the team leads (Scrum Masters), project manager and quality managers (Product Owners) intensively with the stakeholders.

All in all we could save ca. 2 months of development after 18 months project duration. We preferred to invest this in a well prepared change management in the organization, at the expense of ca. 25% of the initial SOW that showed to be nice-to-haves and rather freed up capacities for new and judged to be more important requirements.

Additionally: We were live with the 14^th template release months earlier than originally planned with the final product. Many subsidiaries had their variants already in operation when the initial plan would have started with the roll-out. In total we didn’t save that much on budget side but we won a lot at productivity and business.

An example of Best Practice

Why do I like to tell about this project? Because at that time we didn’t even know that many of our approaches were like today’s agile development methods. And because since then I found in many projects that agile and classic project management do not hurt each other. Coupled right and professional with each other they rather bear high productivity and efficiency potential that would benefit a lot of projects and business cases I see around…

Read another example from my practice with a hybrid recovery approach…

Turnaround for Enterprises with project-driven Business

My last article dealt with the way how to turn a distressed project to success or at least receive a useful benefit from it. It ended with an appeal towards the managers responsible for projects and company not to stop at this point but to use the insights received from the mistakes made to reasonably terminate the ultimate causes for repetitive issues in projects, to achieve a sustainable turnaround.

Theses causes are sufficiently known latest after my many previous articles (see https://eobz.de/category/tips-discussions/), but also looking at the uncounted studies on this subject. In most cases the sources can be found in the company’s acknowledgement of projects in general and of good project management in particular.

Companies with project-driven business model are impacted most

At this business model the dominant business happens in projects, e.g. in customer projects. But also enterprises whose business is vastly influenced by changes that imply a high number or frequency of investments and adaptations in their business are project-driven.

Linienorganisation_E - Turnaround, Organization, Project Management, project-driven Business In Europe enterprises typically have an established line organization structure with functional and central departments. This is especially the case in our traditionally strong industries like Mechanical and Plant Engineering and in particular in privately owned, mid-size companies, but also at consulting and IT firms, engineering and development bureaus etc. Often I find a distinctive own life of the departments, production locations or plants with silo thinking, insufficient communication and cooperation. This becomes very evident with cross-functional work in projects.

A pity if the company actually depends on profitably delivering projects i.e. seamless overall collaboration, and actually not on prospering of single organizational units. In most cases of companies with a traditional set-up but project-driven business this discrepancy can be detected also in the books with revenue, profit and market share decreases. That is because for them the market has changed dramatically in the recent years. These companies urgently need a turnaround not only in single distressed projects but for the entire organization.

Rebuilding the culture must be the first step

Nothing is harder to change than established, beloved habits. Many entrepreneurs and executives already have failed to break up traditional structures and delineated thinking, to “turn” department princes, and to have their enterprise undergo a drastic treatment to achieve the turnaround. To succeed the company culture concerning its projects first needs to change authentically. And this starts at the very top at the executive management.

An intensive Change Management process commences which can’t happen overnight. This is what counts:

Understand where the money comes from. That is no more just having a good product. It also needs to be delivered reliably, assembled and commissioned, at a fair price as contracted. The business actually is no longer product- but project-driven. And by the way the company needs to earn good money (after all). Ergo
Comprehensive instead of local optimization. This means that the profit doesn’t derive from the single production lines and functional departments but in the projects which deliver the whole completely as a package. Efficient collaboration across department borders makes nice company margins, not good single functions’ results alone. It also takes to consequently
Incorporate prestages and suppliers. They also need to be driven by the projects, at least when collaborating with them. Because if they don’t contribute to plan even the own, compelling project planning becomes maculation. Therefore you need to accurately investigate who fits in concerning his performance and organizational maturity, re-negotiate contracts with the new criteria, sharpen and align control mechanisms, expediting and claim management accordingly.

Only if all involved have understood what project-driven business is about, and only if the management backs it up authentically, the turnaround will succeed. And only then you will succeed to implement the reshaping now following without costly resistance.

Rebuilding the organization is logical consequence and fundament

If you focus on your projects’ commercial success your corporate organization needs to fit and reflect this. A profitable, project-driven firm needs to have a good and professional project management. Ergo your company in the future needs a strong

Project management as a core competency and strong department. Quit with functional specialists who lead the projects at the side. Project management needs full attention on planning, coordination and leadership – actually same as with corporate management. Time and objective conflicts of two hearts in the project leader’s chest are poison for concentrating on the essentials. His “thinking” also needs to be project-driven, no longer product love struck. Everybody contributes his core competence, the engineer his functional knowledge, and the project manager his PM skills, for success of the total. Process models and best practices make it replicable and calculable.

Flanking focused resource assignement and legwork

Unfortunately companies mostly have too few of both subject matter experts for all of the important projects at hand. This is why they need a structured and economically effective

Portfolio management, to prioritize their projects objectively and assign their resources for an optimum of business benefit. It’s not gut feeling and preferences, and not at all who shouts the loudest that determines which projects are important for the company. You need to consider that there still will be critical internal projects which are only linked indirectly with the revenue even with a project-driven business model. Criteria for all projects need to be corporate objectives, strategy, risk, profit, balance of initiatives and load capacity of the organization. The means are cost-utility analysis, (may be) Balanced Scorecard and tangible KPIs. Controlling must be consequently according to facts and to time. That is how the discussions und decisions get transparent and safe.

So far with the „new brooms“, but to succeed with the transition for the turnaround you still need a re-shaping at the layout and self-image of

Functional and central departments as service providers for the projects. The previously gone through change in your corporate project culture will help you here. The engineers’ provisions will now not only serve for the product’s perfection but also for the whole task’s delivery to contract. Procurement will not only look at the terms and conditions but also (may be even sometimes with concessions supporting the project targets) at the reliability of delivery. Legal will probe partnership in collaboration; QM controls the project’s product quality and drives process quality (Continuous Improvement). HR will search for skills instead of positions, train for future project requirements, take care for a corporate identity among the employees, etc.

This is no „clean sweep” but indeed an extensive re-shaping of the corporate organization, not only in its structure, because accompanying you need to

Also relaunch incentive systems

All structure and mind-set changes will fall back into old patterns and the turnaround will get stuck if the colleagues will go on to be rewarded for the old instead of the new behaviours i.e. not project-driven as well. Department managers must no longer be measured by their departments’ success and size only, colleague no longer primarily by product quantity or quality. What’s essential is the contribution to the complete picture, the performance in the projects, teaming, reliability, taking responsibility, process improvement, personal growth and skills enhancement, usability and flexibility. These are the success factors for the turnaround and the company’s fitness for the future.

For example Sales will no longer be provisioned for a maximum of sold projects but for good ones with good margins and realistic agreements on delivery. Procurement’s target will no longer be highest discounts possible but favourable conditions which allow suppliers realistic approaches and calculations and still are attractive for prioritized, reliable deliverables. A success measurement could be e.g. provisions on time or low failure.

At HR this is analogous properly staffed projects or less resource bottlenecks at good utilization same time. QM receives bonus for process improvements that further increase efficiency and effectiveness of communication, process flow and cooperation. You probably have plenty more good examples now, do you? In any case the basis for incentives for sure will be a close collaboration and coordination with each other and with the project and portfolio management, because this is also the basis for the turnaround.

Your reward

When your company finally has managed the turnaround and is completely wired project-driven you will not need to fear any benchmark in your industry. You will regain eventually already lost market shares and even more. Most of all you will come back to enjoy your margins and profits, not to talk about the joint success that all colleagues will feel and appreciate. Success makes sexy – that also applies to enterprises !

I hope I could give you some helpful suggestions with these lines. Believe me: these thoughts can be continued infinitely. I find a lot of pleasure in it, and, if you like to, also together with you in your very individual turnaround.

Learn more about the topic organization and project-driven business model…

If Project Management isn’t enough – Programme Management

In recent time I’m frequently asked about the difference between project and programme management. I have already spoken elsewhere about the nature and way of thinking and acting of programs and program managers vs. those of projects and project managers (https://eobz.de/?p=600). Today, therefore, I would like to present an example from my restructuring practice to illustrate this.

Too complex for project management methods

In the following case I was called for an expert judgement on a big, complex initiative which was, in multiple “sub projects”, to develop, customize and implement several modules of a new IT system, involved an extensive data capturing and migration, should operate the system’s subsequent releases, and was planned to overtake the support after the implementation’s completion.

Pretty clear: this was a programme because the single components were interdependently built on each other and lastly would only create the desired benefit for the customer together as a whole. Also it exceeded a normal project by far in terms of dimension and duration. This was bound to go wrong, even if you wanted to manage it with good project management.

Not only deliver, but maximize benefit

“After the books” my programme management (PgM) should create additional value not achievable by managing the single components only. So my tasks in particular were to coordinate the components, focus on the interfaces between each other and with the customer organization, and to ensure the programme’s benefits for the customer were realized.

Project, Programme, Portfolio - project and programme management - example

In program management, this strategic view on benefits for the customer differs fundamentally from the view of a project manager (PM), which is primarily characterized by operational delivery.

In reality the frame conditions for this role image didn’t turn out to be ideal: the key account manager claimed all customer contact for himself, changes to the contract were to be avoided, and from supplier perspective the programme’s focus should have been on ensuring the milestones and margin. So not PgM but multi or super PM?!

Programmes run into distress with normal project management

When I boarded the programme it was already off track: first milestone not met, the customer rejected partial approval though all features were delivered because he claimed insufficient usability and performance. There was nothing about these criteria mentioned in the contract. Additionally there were some new features which the customer desired to get but which the supplier preferred to pick these up after closure of the first contract. Deadlock, hectic at the key account and the legal departments; my predecessor left the programme…

crisis vs. chance - project and programme management - example Well, you won’t receive an assignment of responsibility for such a mega initiative if you didn’t show some real good performance and results as a PM before. But that’s insufficient in most cases for a programme if you are not familiar with additional PgM methodology and action to take.

So I needed to convince my client to change the mega project INTO a real programme; to talk with the customer primarily about his benefits and business case, and to anticipate benefit creating changes as being target leading. In return the customer had to accept to be charged for the change requests though he was in the better situation from the current contract perspective.

Programme management only works together

Only together and with an eye to the benefit to be achieved for the customer by the investment the same makes sense – already with projects and even more with programmes. This might be some kind of balancing act in the rough daily business because it needs to be also profitable for the supplier. So, I had to resolve the impasse between the parties (and also the claims that had already been fixed) and lead them back to the common interests in the initiative.

My client’s response to the customer’s wishes to change and expand the scope according to the current state of business needs on the one hand and the development of new available features and modules on the other hand, as well as the customer’s willingness to pay an appropriate fee for this, to allow the required time, and to provide resources, finally broke the knot. Whereas before they had argued about the content of the contract and “spyed” on each other, they were now pulling together again and in the same direction.

Even a program distressed as a project can be recovered

After the recovery the story met its “Happy End”. The programme went through a not totally painless restructuring, but it could be completed for all parties successful.

It took a little longer than initially planned; the supplier’s margin was a little lower. In return the customer paid a little more, is happy with the scope delivered with more quality and features, and the investment was profitable for both sides.

Surely the supplier’s success would have been bigger if the initiative would have been managed as a programme from the start without the kind of bumpy intermediate phase with impartial balance of power, and thus continuously more as partners than as contract opponents.

That’s why you certainly need to know what makes up a programme – and how you manage this right…

Read more about the topic Program Management…

Increasing Project Management Efficiency – Project Management Office Implementation

Did you ever wonder what your project managers (PMs) do all day long? In one of my other articles here you can read a survey about this, and how project managers are “misused” for “work “foreign for the species”. In addition to that project managers often can only do their job “at the side” on top of hands-on work in the project. Today I’d like to talk about a third kind of project manager’s time misuse, those jobs that could be done much cheaper and more efficiently by others – in a Project Management Office.

Project managers accomplish valuable work

Rewind: Well educated project managers are well paid (or should be). In return they stem a lot of responsibility, keep oversight for their entire team, and ensure that nothing important gets forgotten in the project, and that it becomes a success. This is, taken by itself, a very sophisticated job.

There were some project managers of this kind in the company I’d like to tell about here, also many projects, and thus a lot of work. In an earlier initiative we had already defined common standards for a structured project approach along with appropriate tools and templates. The base for operational excellence in the daily project work was set and meanwhile showed the desired results. Only the project manager’s’ workload hadn’t decreased, and while the projects went tangibly smoother the project manager work day still had 10 and more hours.

As not expected differently the analysis showed that methodic procedures are joined by some routines which would not occur without. Many of these were cyclic, and most of them were to be applied in each of the projects. Though they all belonged to project management the project manager’s time was much too precious and expensive for this, respectively his time would have been used much more efficient at other tasks.

Release of routines increases project managers‘ efficiency

Mappe2 - Projekt Management Office (PMO)

So I received the task to implement a project office for the company which was to centrally pool the repeating routine tasks and do the project managers‘ groundwork. That comprised e.g. organization of travel and accommodation for project team members, booking of rooms and phone conferences, collection and processing of time and work reports as well as updating planning and controlling tools.

Young project people were recruited to start their career path in project management who attended my courses in Project Management basics and in the company’s standard tools. Some of them continued to follow that path later with a IPMA Level D or PMI CAPM certification.

The project managers were released significantly that way; they had more time for planning and analytics thus achieving another push to project quality and efficiency.

Notabene: To implement a performing Project (Management) Office it takes a very experienced project manager who knows what counts. This is surely not a task for a young project manager to earn his spurs !

The Project Management Office (PMO) takes over management responsibilities

When implementing the new career path also a new organizational unit was created, a staff unit outside the traditional, functional line that primarily had to focus on project management. It would have been a logical consequence to allocate the project managers there also with disciplinary competences to consolidate education and promotion in this career path. But my client was not (yet) ready to go that far.

PMO-Office - Projekt Management Office (PMO)

Nevertheless it got „higher“ responsibilities assigned during the second step of my commission: Maintenance and quality assurance of the Project Management standards, execution of the Change Control management and project controlling as well as follow up and processing of risk and contingency management.

The Project Office blossomed out step by step to a Project Management Office (PMO) which dispatched Project Managemnt knowhow fail-safe on multiple shoulders, and which could be used by the project managers efficiency boosting as a shared service. That turned out to be very beneficial when the company was granted two big programs and had the necessary infrastructure already in place with its Project Management Office.

Continuously develop corporate project management

How will this go on now? Well, my contribution already left that much know-how in the company and the Project Management Office that the organization meanwhile is able to identify and initiate necessary adaptations and enhancements by itself. I am currently called to assist only selectively for audits or trainings.

And that is well appreciated because Operational Excellence and internal project management competence was the goal – that was achieved. Now the “expensive” project manager resources can do their high-value jobs very effectively and efficiently, and the company benefits most of this…

Project meets Business

In many of my articles I described which mistakes, made already at the start of a project, merely by default lead to project distresses. But of course I have often seen also things that made even initiatives suffer or die which had been started by the business department in charge in the best intend and with the best means.

There are (nearly) no IT projects

Projects probably are not conducted for their own purpose or as an ergotherapy for the employees. Instead there is nearly always a certain interest of one or more business departments behind it. Either it is to ease the employees’ lives, or eliminate muenzen2 - project, business, responsible cost or mistakes’ causes, or even provide the opportunity of new revenues. The IT then is only a means to an end, shall support the professional process with adequate, automated IT processes. The added value doesn’t derive from the technics but of its application in the business.

That’s why IT projects nearly always are business projects! However it is strange that the responsible managers from business do depart from the project with increasing regularity after having approved the project charter and the budget. Now the IT is to deliver. What the project thus is lacking is the expert judgement needed to have the application look and feel in the end how it best benefits for the business purpose. The “commandeered” subject matter experts submit their wish lists, and the technicians or hired consultants then shall do…

Often a communication issue

Every manager probably once has experienced that business and IT often have a quite different understanding of what could be the resolution for a business requirement. The user side not uncommonly presumes, by the devise „Do what I mean, not what I say“, that the requirements are trivially clear. Actually “you” know for sure how the business process should run ideally and how that all should look like to have it well usable, don’t you?

Or instead the practitioners have a problem but not a clear vision of the resolution. They expect the technicians that they are as deep in the business and just only need to “push” a little with technics. But those have challenges of primarily technical nature, and what they think to be practical will not always be matching with the users’ expectations.

team4 - project, business, responsible The only means against this dilemma is to sit and talk together again and again – business and IT – about the requirements and how to flesh out the realization. Business is in duty and responsibility that their connotations are picked up and understood correctly, nobody else! And this applies for the developers as well as for those who should use it in the end. This also requires the line department head – not the project manager or the IT – to manage his staff’s expectations.

Everything else nearly all times leads to disappointment, delays and increased cost because re-work always is more difficult than doing it right at the first time. Agile project approaches count for this consciously, and for “classic” project management cooperation and support from business is a must, too!

Changes are not a bad thing per se

So, if wrong developments become visible early by good communication and interaction, of if this way you have come to better insights and changed requirements, then this might lead to a rise of Change Requests, but also to an increased business benefit.

For the moment that’s not a bad thing because in an early state the changes are easier to plan in and to execute than later, when you’re up to present a supposedly completed product. It’s only to not let changes creep in uncontrolled and consume time/budget that is needed elsewhere where planned in, thus eventually even jeopardizing the project’s business benefit.

A Change Control process mandatory for all can avoid this. And if the one who orders is also the one who pays, then the business managers will always calculate whether the change really provides an adequate add value. This of course doesn’t help against “politically making the figures seem better than they are” but well enough against wish lists with many „nice-to-haves“ or pedantic “polishing the I dots”.

Need to realize the business benefits

If all have well cooperated and communicated, and if not at least due to this estimates and planning was realistic, then there should be nothing blocking the road for a successful project. But the project not only needs to be completed as planned to be successful, it also needs to achieve its expected benefits to be realized. This usually again happens at business by using the Henning Zeumer 72 dpi 17724 - project, business, responsible product, results or capabilities developed in the project.

Business management is therefore responsible that the project’s product is used as intended, i.e. first that the product has been designed and realized as needed by the business, and second that the functional organization accepts and uses it, not keeps to “old habits”.

The latter aspect you can assure with good user trainings. In cases where projects have extensive impact on daily work and organization the mangers in charge of the project should plan for an intense, supporting Change Management going along with the project, and have it conducted with the lead personal and staff. This is the way “rubber gets to the road” and the business case is achieved in the end. You see: It really was a business project !

Doesn’t apply only for IT projects

The examples shown here should not keep managers or executives comfortable if they just don’t have an “IT project“ in their responsibility. Same mistakes similarly happen in rather all other projects as well. Be it the product management giving not enough attention to its R&D projects, or only revenue and profit potential is considered at a merger, but not proper back office, application and people integration, or a civil construction where the individual crafts are not sufficiently and continuously coordinated with each other – the result always will look like the same.

That doesn’t mean anything else than that those who ultimately want to draw the benefit from a project or program, an initiative or investment – for whose business all the money is spent – need to be very aware of their responsibility for success.

But if they prefer to delegate it away and don’t (want to) contribute, business projects will repeatedly get off track, take longer, cost more, and lead to more or less disappointment. This is my advice for superiors: Careers need to have a proven success track, not troubled or even written off projects…!

Learn more about the topic…

Does your Organization Structure still fit your Business ?

Projects are the part of the enterprise where it is adapting to changing requirements from market, laws, society etc. Corporate changes and advancements always happen in projects. Without these changes there would be no progress but stagnation in the company, soon followed by “death”. So projects are a must in all companies, and they are inevitable for their growth and future.

This fact alone already implies that the project management organization of each enterprise needs to have a maturity sufficient to conduct the organization’s projects in a reasonable way. If on top the business model is project-driven with many customer projects or frequent adaptations, this implies increased requirements on how projects are done in these companies.

Established Structures often are Road Blocks to Success

At many companies with project-driven business model their established functional or matrix structures are obstacles for an optimal set-up and conduct, and economical success of their projects – and the root causes for repeating distressed projects.

There is usually a functional line structure established as governance organization structure in industry and manufacturing due to the dominant division of work, where tasks can be progressively elaborated and delegated according to product components. In many cases this goes along with central functional departments like finance, procurement, HR, QA, and sales, where the latter is often grouped by regions or customer clusters.

On the opposite projects do have completely different characteristics: Each project is unique, i.e. a new product, service or capability never seen before is developed for the company. So the projects’ progress is harder to predict and always in an uncertainty situation. Product R&D projects in manufacturing are a good example for this.

Analogously a primarily project-driven business or even a pure project business with customer projects has the same frame conditions. Work and value add are done with humans, are dependent on their availability and skills. Therefore the importance of coordination and efficiency of resource allocation and processes are primary for optimal throughput and results, and it takes special controlling and governance mechanisms suitable for these environments. The need for communication and information exchange is much more dominant than usual in functional structures.

Common Conflicts

Not only that established organizational structures and cultures are not made for such kind of working, they mostly are in direct conflict. Common and frequently repeating symptoms are

insufficient clarification of scope and quality with the customer,
unrealistic promises by sales,
resource conflicts at projects vs. functional departments,
project manager’s lacking authority and management support,
local instead of cross-department (= corporate) optimization of processes, resource planning, budgets, margins, risk, and responsibilities,
multiple, redundant, uneconomic performance of work in many projects
unreliable controlling of suppliers and own project staff
and over and over again projects in distress, delayed, with cost overruns, maybe penalties, or even cancelled at all.

With the increasing competition from a more and more global market environment the customer’s position in the market gets stronger, and a profitable course of projects becomes an imperative of thriftiness for the entire company.

Now imagine for a moment your company’s organization supporting this business model even optimally…

Examples for project-driven Enterprises

Typical companies with a project-driven business model are e.g. IT development, implementation, and integration, consulting companies, plant engineering and engineering bureaus, aircraft and space, as well as defense companies, civil construction, R&D, event business, and so on. But also enterprises with a strong influence of projects on their business like all regulations-sensitive industries (e.g. banking, energy sector etc.), high technology industry (engineering, capital goods, automotive, electronics etc.), as well as many public authorities and services.

In all these cases I find the above described patterns of burning money again and again. In all these cases a strategic transformation of the organization, structure and culture with corporate form following its function would unfold immense potential for profitability and fitness for future for the company.

durchschlagend nachhaltig E If the money is earned in projects their margin is superior to the simple revenue of the single departments and plants. But it needs a re-built of existing hierarchies, responsibilities, incentives, mind sets and priorities etc. to transform even a project supporting organization into one well aligned to a project business.

Advantages of a strategic Transformation

In a project-oriented organization structure resources are reasonably assigned where they serve the business best, independent from their assignment to the lines. Skills respective staff can be optimized provided or hired or trained according to the business (= project) requirements. The activities in a project-oriented organization is easier to be focused on the business objectives, project selection follows the optimum of business benefits. A reliable delivery of projects and investments is a must; a profound know how and proven success record here is becoming a strategic market advantage.

Project-oriented Organizations are flexible: resource assignments for projects can be done efficiently from a pool, i.e. skills are utilized at the right time in the right project. If priorities or business requirements change reactions in changing resource assignments are flexible and fast.

There are lots of experiences with project-driven organizations. All have in common that profitable projects mean profitable companies. I recorded these experiences in my recently released book “Success and Growth in project-driven Enterprises – Motivation, Challenges, Transformation” (ISBN: 9-783754-397985, and as e-Book ISBN 9-783755-719069, e.g. at Amazon https://buff.ly/3xKz4Lb). Who doesn’t want read first shouldn’t hesitate to seek a conversation with me.