Tag Archives: programme management

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 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.

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