Blog

Project Server or EPM Implementation Approaches

in Project Server
1 Sep 2010 |

After few years of experience with implementing Project Server or (Microsoft EPM), I’ve seen many approaches to implement it, successfully or otherwise.

 

In summary it all ends up being one the following approaches:

 

  1. Two Steps Approach: where you go through the standard approach of collecting requirements, design, then develop and test.

Notes on this approach:

 

  1. Perform the scoping exercise (or collecting requirements) doesn’t produce always an “Implementation Plan” (i.e. how the organisation is going about implementing the tool, what is the size and the shape of the change, what would the training required.
  2. The organisation that doesn’t have a good Project Management maturity level, won’t know what it wants from the tool (i.e. unable to communicate the right requirements) and will start discovering more requirements as it start using the tool.

 

Conclusion here; Project Server / EPM brings a big change to the organisation, if the organisation is not in the right level of maturity to communicate the exact requirements, and manage the change the tool brings, there is a good chance of failure. However this approach if done well will decrease the organisation’s cost of implementation.

 

EPM or Project Server help organisations to enhance their Project Management maturity but is not a magical solution to resolve all your challenges.   

 

  1. Agile Approach: where organisations install the software, then perform a number of sprints of:
    1. Introducing a functionality (by demonstration and basic configuration)  
    2. Usage with real data
    3. Issues fixing and stabilisation (further configuration and customisation)

 

Example: Introduce Resource Management as a concept; demonstrate the different ways how Project Server handles the concept, and apply basic settings. Then upload a team or a limited number of resources. Exercise the functionality through a pilot for a period of time (shouldn’t be too long) where you can stabilise the tool apply further configuration, fix any issues and document training documentation.

 

Conclusion here; this approach will bring the change gradually and will have a very good chance of increasing organisation’s maturity and decreases the risk of failure. However this approach requires long commitment and in many cases more investment. One the most common risks with this approach is the ownership of the change or the tool might change through the change lifecycle and the change losses its momentum.

 

Each approach has its own pros and cons, deciding what approach suits you best, is highly dependent on your organisation project management culture and maturity.