Henning Zeumer - Henning Zeumer Projektmanagement

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…

Program Managers need Grip on Reality

Program Managers need to keep close contact to project managers, even to the work floor. Do not only concentrate on communicating upwards! Your program marketing is better if you can tell stories of it. If you are not inside the program you will lose oversight, get unconfident with the status, start beating subordinates without reason, and even loose rapport at your superiors.

Why not short-time working in projects?!

Sparschwein - Lessons Learned: short-time working

When budget cuts risk forcing you to set your project on hold it is considerable to continue with reduced scope or speed rather than to roll off a good team. To save expenses part-time resources continuing on low effort (short-time working) may be preferable over a complete freeze and ramping up new resources when the project resumes.

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

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.

block2 - Project 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…

2015 Pulse of the Profession – actual PMI report is published

This year again the Project Management Institute (PMI), being a leading professional institutions in project management, continues its research series with the actual report “The Pulse of the Profession”.

This time the study’s and findings’ focus ist hat enterprises which consequently live the fundamental basics of project management achieve significantly better results in business as well.

PMI Pulse 2015 Those basics include:

Fully understanding the value of project management
Having actively engaged executive sponsors
Aligning projects to strategy
Developing and maintaining project management talent
Establishing a well-aligned and effective PMO (project management office)
Using standardized project management practices such as Risk Management, Knowledge Transfer, use of agile/incremental/iterative practices in project management and benefits realtzation maturity throughout the organization

Such companies, called “High Performers” in the report, have 2 1/2 times more projects fully meeting their original goals than less mature organizations, and they waste 13 times less money !

But besides this main result it needs to be noticed that the number of “High Performers” remains steady at only 12 percent. Laila MT Faridoon, Director of the Chairman’s Office at Roads and Transport Authority (RTA) therefore assumes: “I believe more focus on selling the concept of OPM (= Organizational Project Management) and its value to the C-suite is essential to cause a noticeable change.” Thus good project management and a mature PM organization keeps on being matter of the boss , and without acknowledgement of its value by the top management businesses will go on stagnating “low performing”.

But read it yourself. Find the actual PMI report “The Pulse of the Profession 2015” for download here or directly at PMI at http://www.pmi.org/learning/pulse.aspx