X hits on this document

18 views

0 shares

0 downloads

0 comments

4 / 8

If you’re now working on a Microsoft EPM Solution deployment, you’ll find an organization in one of several states:  

1.

There is no matrix  

The organization is completely silo-based.  Each department head manages his or her own department as if it were a subsidiary of the larger organization.  Budgets are summarized upwards through the departments in a hierarchical fashion (think of an Organigram).  When a project is initiated it is done within each department even when resources might be required from other departments to complete the project.  If the project can’t be completed with the resources from the department that is managing it, then outside resources are negotiated as inter-department requests.

That actually doesn’t sound too bad until you try to manage such a project.  If almost every project requires inter-department resources, then figuring out the priorities between groups is impossible.  There is no incentive for any one department head to relinquish control over the priority of his or her own resources.  It’s counter-intuitive to give up such power, so any project that can’t be completed within a single department suffers.

Moreover, when we talk to executives who are one level higher than the department heads, the universal lament is that they cannot get any resource capacity planning.  This makes perfect sense.  There is no cross-department structure for aggregating the information we’d need for resource capacity planning nor any incentive for each department head to submit to the centralized prioritization that would be required for such an analysis.

It’s entirely likely in this situation that we’ll find not one but multiple project offices—one per department which cooperate very little with each other.

Deploying the Microsoft EPM Solution into this kind of scenario requires doing some thinking about how to adjust the organization at the same time.  Often we get calls from these kinds of companies asking us to do the impossible.  Train hundreds or even thousands of users, get Project Server installed and be in production in a couple of weeks.  The expectation is that because the company has purchased a centralized enterprise project management system, then the organization will immediately line up and operate as a centralized matrixed environment.  It’s an expensive fantasy.  Inevitably, we have to talk with senior management about how the organization will have to be changed.  That’s typically not great news for management who were hoping that just purchasing the software would be enough of a commitment to have everyone change.

We start such projects by working on plans for a centralized project management office and centralized project management procedures.  Project Server gets introduced slowly from the middle out.  It’s not uncommon for such projects to take 12 to 24 months until the entire organization is finally involved.  We just re-started such a project after a 2½ year delay while they worked on their own to create a PMO.  

2.

There is a balanced matrix It’s great when this happens but it’s unfortunately quite unusual.  Maintaining a balanced matrix requires constant adjustment and care.  But, when we do find a balanced matrix, we’re also likely to find a highly evolved set of procedures, defined roles, and a process that's well understood by everyone involved.  Deploying the Microsoft EPM Solution into this kind of organization is the best-case scenario.

Page iv

Document info
Document views18
Page views18
Page last viewedTue Dec 06 16:08:35 UTC 2016
Pages8
Paragraphs63
Words2740

Comments