Home » Blog

Changing Enterprise Through Projects. Are Projects Evil?

Posted by Darko Bohinc in Architecture, Project Management on Monday, May 10th, 2010

Many organisations use “Projects” as the tool for enabling change and realising benefits within their Organisation.
It seems to be the “silver bullet” that will solve all of the organisation’s problems.
This is evident in the position and power held by The PMO (Programmes/Project Management Office),
which controls and executes projects within an organisation. Executives hold it
in high regard. Who wouldn’t? All projects are based on a sound business case,
a rigorous selection and funding process has been applied, PMO has people that
have experience in many world-known project management methodologies and
frameworks under their belt. It’s all about just getting on with the work.
Isn’t it? Are projects actually evil?

Many organisations use “Projects” as the tool for enabling change and realising benefits within their Organisation.  It seems to be the “silver bullet” that will solve all of the organisation’s problems.  This is evident in the position and power held by The PMO (Programmes/Project Management Office) that controls and executes projects within an organisation. Executives hold it in high regard. Who wouldn’t?

  • All projects are based on a sound business case
  • Projects have been through a rigorous selection and funding process
  • The PMO has people with experience in many world-renown project management methodologies and frameworks under their belt

So it’s all about just getting on with the work, isn’t it? Are projects actually evil?

In the blog post Real EA’s Do Not Wear Ties, by Brian Hopkins, there is an excellent example of a “fictitious” project that, with all good intentions, did not deliver appropriate outputs. Three key problems are a result of weak assumptions, which seem to be quite common for many projects:

  1. Change has little impact – Everyone knows that we only need to change or introduce IT Systems and everything else just falls nicely into place.  People and processes just need to adjust to accommodate the new system, so a little training is all that’s needed to make everything perfect.
  2. There are no ambiguities – In an organisation, everyone knows, terms like customer, product, code, etc. mean the same thing to everyone, and everyone surely uses them and needs them in the same way. There are absolutely no ambiguities.
  3. The Business Case contains 90% of the solution – The Business case, everyone knows, is always based on a well thought through solution, and any assumptions (implicit or explicit) represent only minor issues that will be solved or mitigated during delivery. It is acceptable to not know where you are starting from, and to progress based on “guesses and crossed fingers” because the numbers and general solution look good.

Although these mistakes certainly impact project success, we should perhaps consider that the true underlying reason for project failure was in delegation of “thinking about the enterprise” to PMO and the individual Project.  In particular, we seem to be failing when delegation occurs to IT centric delivery projects (see Problem 1).

The role of PMO and the Project is to execute delivery of well defined outputs under agreed time/money/resource constraints.  It is all about delivery of outputs and effecting change. The mantra is: outputs, on time and on budget. There is usually no time to think about the Enterprise, or the Project’s impact on the Enterprise.

So, who or what should be thinking about the Enterprise?

Perhaps the fact that PMO is a centralised function, and that many parts of an Organisation use Projects as a tool for effecting change, somehow leads organisations to conclude that thinking should also be organised/done by PMO/project as well.

I am not dismissing the value of The Project, PMO and associated project management disciplines. They provide absolutely essential tools and services to an organisation. I am rather trying to point that it appears that they are “conveniently” used as a vehicle for delegating responsibility of “thinking about an enterprise” to delivery groups. One less thing to do for executives and business owners, one more thing to do for PMO/project. It’s just work!

Over time, we seem to have ended up with the following formula to describe change within an Organisation.

If the Project is a function in an Enterprise then:

Output = Project (enterprise thinking, introduce or change thing)

or, in some Organisations:

Output = Project (introduce or change thing) + [time passes] + Project (enterprise thinking, remedial action)

Wouldn’t it be more appropriate to ensure that correct level of thinking and strategy is done by people responsible for thinking about enterprise, before delivery focused PMO services are utilised? At the end of the day who is in charge of providing scope to PMO/project? Wouldn’t the following formula be more appropriate?

Output = Project (enterprise thinking) [1...m] + Project (introduce or change thing) [1...n]

Although the Project, as a tool for organising resources and delivering outputs, must be used for both “introduce or change thing” and “enterprise thinking”, the motivations, scope, success criteria, and constraints relating to each are completely different. So, perhaps, just perhaps, they should be kept separate. Why?

Why Keep “Enterprise Thinking” and “Change” Projects separate?

  1. The realisation that some sort of organisational change is almost inevitable for any but very simple business problem comes too late (see Problem 1). This possible change is usually not a recognised risk for the project and is now an issue (impacts scope/time/budget, etc.) that has to be somehow resolved within project constraints and motivations. A nice example of this can be found in Nick Malik’s post Does Application Portfolio Simplification Solve the Wrong Problem. More often than not, rather than stopping the project and regrouping, Projects put blinkers on and proceed with “she’ll be right” expectations because, for them, it will be right and thinking about the Enterprise will almost certainly slow them down. In rare cases, perhaps, another project is put in parallel to sort out that simple organisational change problem. And then research says: more than 50% of IS projects fail … nice one?
  2. Thinking about the Enterprise is a tough problem:
  • What have we got today?
  • What are the most appropriate capabilities for the future?
  • What is most appropriate distribution of responsibilities between business capabilities?
  • What minimum interactions between capabilities are required to deliver our product and services?
  • What are most appropriate transformation and change paths?

    • Experience suggests that delivering ‘Enterprise Thinking’ output, within a commercial project environment, just does not seem to work.

    Do not get me wrong, portions of enterprise thinking can be delivered within a commercial project, but only and only if initial enterprise thinking and strategy work was already done before delivery focused projects start. However, “beware what and how much you delegate” still stays.

    Organisations that do not recognise value of this work separation, and continue bundling these different kinds of project together, are likely to be experiencing the same problems over and over again — which certainly would be detrimental to their business, if not exactly evil.

    Comments (4)

  • Doug Newdick says:
    May 10, 2010 at 1:46 pm

    Is the problem that the project is doing the thinking about the enterprise? Or is it that the project is doing the thinking about the enterprise implicitly without it being explicit that this is what it is doing, and therefore without the appropriate inputs and governance of that thinking? That is: no realises that this is what the project is doing or has to do in order to succeed at delivery. So perhaps it isn’t necessary to separate the enterprise thinking into a separate project as long as it is made explicit that this is part of what a project has to do.

  • Nick Hynes says:
    May 21, 2010 at 9:20 am

    Hi Darko,

    Nice blog. We’ve been struggling with exactly the same problem, and have informally come up with a similar solution – we now have some project deliverables being governed by a TS steering group and guided by an Architect as the Product Owner.

    Are you familiar with the Ross, Weil & Robertson book ‘Enterprise Architecture as Strategy’? They talk about a system of linkages where the PM represents a narrow group of project stakeholders and the Architect represents a broader group of enterprise stakeholders. There is a natural tension between the role of Architect & PM.

  • Darko Bohinc says:
    June 1, 2010 at 10:57 pm

    Thanks Doug,

    No, it is not problem that project is thinking about the enterprise, in fact project should be used as a vehicle managing this activity. Although, making enterprise thinking as part of a immediate delivery projects looks like a viable option, from experience, success criteria for those projects seems always be loaded towards delivery of the final outputs. Everyone’s focus is on “we’ll have a new system” and that’s why project got allocated money in the first place. So, if by chance, enterprise thinking is introducing delays, at the end it will all boil down to “quantity over quality”.

    In many cases, results of enterprise thinking require changes outside of the immediate project scope, which becomes a challenge for the project. That’s why it seems that, at least initially, organisations must separate the two, until major building blocks are identified and defined. Only significant shift in organisation change process maturity would allow mixing significant enterprise thinking with immediate delivery project.

  • Darko Bohinc says:
    June 1, 2010 at 11:40 pm

    Thanks Nick,

    Doug was suggesting approach similar to that you have already informally adopted. I am not sure about the implications of the word “informally”, but nevertheless a step in the right direction. I assume that you are experiencing tension between PM and Architecture stakeholders, as recognised in the book?

    If so, when project time starts running out, whose success criteria get more attention from the Project owner? I suspect in most of the cases PM’s. Correct?

    My whole point is that any tension and negotiation about how should business capabilities be enabled (vision and delivery rhythm) should be sorted out between enterprise architects and business capability owners during the “enterprise thinking phase” before the commercial projects, run by PMs on behalf of business capabilities owners, get initiated. If that is achieved, PMs would be managing delivery of the projects that were agreed jointly, through planned activity, by business owners and enterprise architects. So, scope and success criteria definition tension would disappear.

    Not an easy objective to achieve, as it does require formal recognition of the problem and significant shift in organisational thinking.

    • Add your comment