Introduction.
As mentioned in this post 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. I just had to put an article in between with some subjects, I find important due to the strategic value an IT project represents.
I have in most of my career 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 “play by the book” scenario (Follow the chosen project management methodology step by step) or “getting things done” scenario (focusing on what is needed) using the available resources, when they are available for the project.
Here in this post I will share some reflections and some observations from real life, working with IT Implementation in 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.
A communication strategy for 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 humble opinion the management attention for 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”.
It is my experience using the momentum achieved up to the “Go-Live” for a short “Generation 1 Phase”, will provide the business a much better Return of Investment – despite not being immediately measurable in the monthly financial report. The organisation do have a great awareness among the participating resources immediately after a “Go-Live”.
The customer focused implementation project
Working with an implementation project I find a huge difference between being the internal customer project manager compared to being the project manager representing the vendor.
The internal customer project manager will use the defined framework within the organisation and will in most situations know how to deal “result oriented” with challenges caused by the customer organisation.
The project manager representing the vendor will often have to work accordingly to the defined framework specified by the contract.
There are unfortunately a risk for a 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 vendor’s project manager as responsible for activities like the future organisational role and responsibility or business processes after “Go-Live”.
The 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.
Team building events
There seems to be a tendency to reduce or cut away a lot of non-revenue generating activities in many organisations, like having a team building event, when starting a new project/ project phase. In my humble opinion executing a team building event will have a positive huge impact on the long term result.
In the scenario where a “vendor project team” will have to work together with a “customer project team” the team building event will have a great value – especially if repeated a couple of times. Both teams are expected to cooperate immediately and be effective from day one, despite any difference in culture or professional competence.
Documents delivered by the project
I have observed many companies implementing the full available package from the preferred methodology (PMBOK® or PRINCE2) and defining them as mandatory documents to be issued by the project.
I do recommend to have a company critical review of this package. Project documents should be categorised as Mandatory, Relevant and Optional related to the kind of business the company deals with. The company have the option to issue one mandatory project document to be used as reference. This document consist of table with all available project documents, sorted by defined phase & category and 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 be added or removed as time goes by.
Documents delivered by the project – Use Cases
The Use Case is a valuable document for the quality assurance of the delivery, but is far from given the right attention seen from my experience in both the Vendor and the Customer role.
I do recommend that the customer request the vendor to hand over the set of Use Cases documenting the (default) functional work flow in the delivered IT system.
The customer have option to use the vendor set as inspiration, when 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
When the implementation project involves a vendor some customers do not allow the vendor to communicate directly with the stakeholders at the customer locations. Unfortunately this can lead to situations that delays the project.
Every implementation project requires a regular communication channelled to the end-users, the stakeholders and the Steering Committee. This communication needs to represent a shared point of view from both the vendor and the customer PM’s.
I do recommend to be open minded for the human factor here – I do believe that it can be an advantage to let the vendor communicate with end-users. The only requirement here is the commitment to only accept a change request addressed through the customer project team.
Any issues in relation to the communication will have to be addressed to the Steering Committee.
In the previous posts I have shared a lot of insights related to what the management should focus on in terms of preparations for and execution of IT projects.
The “Project Management Methodology” are needed for many activities – however it requires an effort in both training new and maintaining achieved competences among participants and in general organizations.
Unfortunately we are facing a management tendency as “maintenance of achieved competence” are seen as a cost rather than the strategic long term value adding investment it is.
This article was published initially on LinkedIn on 5 December 2017 (Some modification of the wording has been executed in this version).
Image Credits:
| The Home Work Shop | Photo by Jack Douglass on Unsplash |
| The Business Portal | Dreamstime Free |
| Team Planning | Photo by Jason Goodman on Unsplash |
| Project Deadline | Photo by Kevin Ku on Unsplash |
| Looking at the puzzle | Dreamstime Free |
| Use Case Planning | Photo by UX Indonesia on Unsplash |
| The Risk Taking | Photo by Markus Spiske on Unsplash |
| Communication | Dreamstime |
Thank you for having read this article – hope you have enjoyed it and that it has given you some ideas of where to start improving your own business or individual role, when it comes to the use of IT.
Best wishes for the future.