Category Archives: all

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.