Reflections – Implementation Project in a revenue driven organisation

Introduction

As mentioned in my first article related to an implementation project I realized, I had to split the article in two parts; one related to Project Management in general and one with both reflections and observations related to project management of IT implementation projects. In between I just had to put an article with subjects, I find important due to the strategic value an IT project represents.

I have mainly been executing project management either representing or as an employee in a revenue driven organisation.​

A general challenge for the project manager in these organisations is to balance the “play by the book” scenario (Follow the chosen project management methodology step by step) or the “getting things done” scenario (focusing on what is needed) when the resources are available for the project.

In this article I will share a combination of observations, reflections and recommendations taken from real life experiences, working with strategic IT Implementation in various matrix organisations located at several geographical locations.

Time line in general

Most strategic IT projects start with the execution of an investigation phase, followed by the presentation to the management team with a recommendation to start the project. In most scenarios there will be time gaps between the investigation activities, the presentation of proposal and the management decision.

Frequently communication during this period will keep the awareness alive within the receiving organisation. It will also limit the risk for scenarios, like the one I have experienced; representing the vendor I had to (re-)communicate the customer business strategy and expected benefits in order to motivate some customer teams to change from lack of engagement in to an interest in and acceptance of the new IT system.

Time line for an implementation

I have seen the scope of many projects being shaped to a minimum in order to achieve the management approval and successful Milestones. With respect to the strategic value an IT project represents for the business, I find this trend very risky.

In my opinion the management attention in most implementation projects are disappearing too early, i.e. at the time where the organisation are comfortably using 40% to 50% of the available features/ functionality. This stage I define as “Generation 0”.

When I was given the training as IT Project Manager the project Time Schedule included a 1 to 3 month “Warranty period” after “Go-Live” in which focus were to trim the installed version.

I have a few times used the term: “Generation 1” defined as the 80% usage of available functionalities installed. I do see a parallel between the “Warranty period” and “Generation 1”.

The end-users (customers) do have a great awareness immediately after a “Go-Live”. Using the momentum achieved up to the “Go-Live” for a focused “Generation 1 Phase” (3 months) will improve the Return of Investment – despite not being immediately measurable in the monthly financial report. 

The external project manager will often have to work accordingly to the defined framework specified by the contract. There are unfortunately a risk for having this framework written by resources in the customer organisation without experience in managing complex projects or operating in a matrix organisation.

I have seen contracts defining the external project manager as responsible for activities that belongs within the customer organization like the future organisational role and responsibility or business processes after “Go-Live”.

The external project manager representing the vendor can only be responsible for activities or tasks controlled by the vendor, i.e. related to the IT delivery. All issues related to future changes in established roles and responsibilities or business processes must be managed by a project manager representing the customer organisation.

The assignment of team members

Every project framework uses the same guidance in relation to assigning resources to the project. The reality is a huge difference in how the members of the project team are assigned. One thing is for sure though; the longer a project live, the higher the risk will be for a replacement of key resources among the project team members.

The mature organisations uses the “Resource Contract” being aware of the risk for situations, where the business priority forces the resource owner to temporary withdraw the resource from the project. Using the “Resource Contract” scenario gives the project manager an opportunity to raise a flag, when resources cannot deliver the work hours agreed.

The less mature organisations just assign tasks to the resource without providing a guideline in how to prioritize the assigned tasks next to their mandatory activities. I have here observed a tendency to (without notice) replace the assigned resource without any concern related to knowledge of business area, achieved knowledge within the project activities or seniority within the company.

Team building events

In my opinion executing a team building event will have a positive huge impact on the long term result. Unfortunately many organizations chose to cut away non-revenue generating activities without evaluating the strategic value.

Project teams are expected to cooperate immediately and be effective from day one, despite any difference in culture or professional competence.

As soon as the members are a mix from another department/ organization or an external vendor the team building event will provide a great value to the project – especially if repeated a couple of times during the project.

Documents delivered by the project

I have observed many companies implementing the full available package from the preferred methodology (PMPOK® or PRINCE2) and defining them as mandatory documents to be issued by the project – despite it is recommended to have a more realistic approach.

With respect to business area the company deals with, I recommend to issue a company document containing a list of available project documents categorized as Mandatory, Relevant and Optional.

In order to secure that the project has evaluated which documents to include, the company uses one mandatory document as reference. This document consist of table with all available project documents, sorted by defined phase & category plus two columns to be filled out by the project manager: “Included/ NA” & “Comments”.

Using this reference document as one of the few mandatory project documents will be a “win-win” for the company. The project can focus on generating the documentation valuable for the business, and at the same time document the evaluation of each available company project document – assuming a “N/A” requires a “Why” statement.

Being in a world continuously changing I recommend a yearly assessment of the internal project documentation. Depending on the actual business activities some documents might change category, be added or removed as time goes by.

The customer will then have the option to use the vendor set as inspiration for generating their own set of Use Cases. I am aware of this requires resources, but having IT systems at enterprise level in a Matrix Organisation, the Use Case is one of the best reference documents forward.

Document delivered by the project – Risk Analysis

Dealing with a larger implementation project the Risk Analysis often mirrors the political interests rather than the real risk scenario. Larger implementation projects will include a project team from both the vendor and the customer, some resources responsible for a specific delivery and several stakeholders.

In some implementation projects the contract specifies the vendor to issue and maintain the main Project Risk Analysis, however it has to be verified by the customer.

A Risk Analysis issued by the vendor could consist of less internal issues related to lack of resources, deliveries or decisions required in order to pass a Milestone and a majority of issues related to external deliveries, i.e. resources available by the customer, lack of access to customer infrastructure or lack of customer decisions.

A Risk Analysis issued by the costumer could consist of less internal issues related to lack of resources, deliveries or decisions required in order to pass a Milestone and a majority of issues related to external deliveries, i.e. lack of resources available by the vendor, lack of competence within the vendor project team or lack of vendor delivered documents.

The most accurate scenario in this case is a Project Risk Analysis generated and regularly maintained during a work shop with participation of both project teams.

The result generated using this methodology might not be appreciated by any of stakeholders or the Steering Committee, as it would include “sensible” information of real issues related to resource assignments or lack of management decisions – which often by the contract are defined as “Non-existing”.

Who decides which Risk Analysis is representing the actual project?

Despite the political issues a true Risk Analysis will generate, I find the win-win situation to be maximized using the best scenario, i.e. the united project team work shop version.

Communicational challenges during the implementation

I have experienced that some customers do not allow the vendor to communicate directly with the stakeholders at the various customer locations. Unfortunately this can lead to situations that delays the project.

The IT platform design is complicated

As I mentioned in this article then I am convinced the companies will need to catch up on having the full overview of the match between the Business Strategy, Business Processes, Data Processes and Legal requirements are documented.

I can recommend to use the models mentioned in this article for documentation – it is better to use a reference model than no reference model at all.

In this article I addressed why securing the match between the Business Strategy, Business Processes, Data Processes and Legal requirements are critical.

In this article I mentioned some important considerations as end-user GUI (Design/ open for customizing), number of mandatory steps in the use scenarios, stability, version control, security, patch support, open standards, interfaces, migrations, reference to defined standards, how changes to GUI flow are configured, etc.

The “Project Management Methodology” are needed for many activities – however it requires an effort in both training new and maintaining achieved competences among all participants in order to gain its strategic long term value adding.

In this article I had a short in between reflection to some very important subjects with a strategic impact to the business.

Next in line

With reference to the “Top of the Iceberg” analogy then I have just scratched the surface of the complexity a company will have to deal with when working with their IT platform.

In my pipeline is an article where continue my reflections related to the “IT Implementation Project” as the strategic asset it should be.

You are welcome to ask questions, comment or come with a proposal for the next topic in my series.

Thanks you for being with me in reading this article – hope I have inspired you to take action.

For now I wish you a pleasant week – coming closer to the Christmas Rush just remember time are our most valuable asset.

This article was published initially on LinkedIn on 15 December 2017. I have made some adjustments to the content in this version.

Image Credits: