Reflections – The Implementation Project Scenario – in between

Introduction

As mentioned in my first post related this scenario 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.

Sometime you discover that you missed something in your planning – in this case I had some reflections related to “in between” factors, I see as required to secure the strategic IT implementation project being a long term success,

Here in my eight article I will share some reflections and observations related to management, the technical platform and the Proof of Concept phase – subjects I find to be important for a continuous long term return of investment.​

Implementing new IT solutions – CxO level

One of my observations while implementing a new and/or strategic IT solution, has been the importance of a proper and continuous management focus at CxO level. IT is just the technical part of the activity, where activities related to business processes and training of end-user are more critical in terms of achieving the goals identified in the business case.

There is a strategic benefit in using the Business Process Re-engineering mindset during the creation of the Project Charter and again during the Project Planning Process.

Giving the project this kind of focus shows an awareness to the impact a new IT solution will have on critical business activities, i.e. processes, roles and responsibilities.

The CxO management group have to acknowledge the need for assigning a specific resource to handle the non-technical activities, starting already at the time of the pre-study phase (Project Charter).

Seen from a management perspective it can be challenging to have two persons sharing the responsibilities. I find the best approach here to have the IT Project Manager assisted by a project manager responsible for the non-technical activities and letting both appear during the Steering Committee meetings.

In order to reduce the risk for critical errors when updating, you need to have Quality Assurance, where you can test the latest changes using real data before implementing the new changes in Production.

You need Test in order to verify, that the required change behaves as expected using realistic data before uploading the change to Quality Assurance.

You need Development with an updated copy of your live configurations when developing or changing existing configurations or functionality before transferring the new features to Test for verification of that you got what you expected.

Technically with the solutions available today it is possible to create the Quality Assurance, Test and Development on the same physical hardware using a virtual server environment.

The critical part is to secure a proper version control management when uploading changes.

Another challenge related to have a full functional copy is to have a similar design available for all the other systems to which data are exchanged.

Proof of Concept – mandatory

In my opinion a Proof of Concept scenario using recognizable business data should be a mandatory activity in every implementation of a new IT business application solution.

Prioritizing the Proof of Concept Phase will bring your Implementation Project much closer to both the expected result and a realistic time line.

Focusing on creating an operational solution for our customer, I would say that we managed to twist Scrum, Agile and Extreme Programming in to an operational and fast way of both testing and demonstrating the requests for a change without exceeding the total budget.

There are situations where present business needs have changed since creating the requirement specifications included in the contract.

This leads to another advantage using the “Proof of Concept” scenario; the opportunity to identify any differences between prerequisites within the new IT system compared to the existing business processes or organizational roles & responsibility.

The IT platform design is complicated

As I mentioned in my article related to present challenges 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 recommend using the models mentioned in this article related to documentation – start using a reference model will be beneficial in the long term.

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

I mentioned in this article related to the design 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.

In my first article related to implementation projects I shared some reflections related to project management in general. The “Project Management Methodology” are needed for many activities – however it requires an effort in both training new and maintaining achieved competences among participants.

We need to see “maintenance of achieved competence” as the strategic long term value adding investment it is.

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

Image Credits: