Reflections – The Implementation Project Scenario – part one of two

Introduction

When writing this article with some of my reflections related to Project Management in implementation projects I realized, that I had to split the article in two parts; one related to Project Management in general and one including my observations related to project management of IT implementation projects.

Here in my seventh article I will share my reflections related to project management in general.

I have noticed a practical difference between the role & responsibility I have been given to operate within and the Role & Responsibility other project managers are given in Europe and USA despite the use of the same foundation, i.e. PMBOOK® or PRINCE2.

 It might be because of the kind of projects I have been managing, but the results my teams and I made were achieved based on commitments for delivering a stable solution and the relevant documentation rather than filling out all documents within the chosen model for project management.

Despite the employment as Project Manager then I have in reality taken and been operating in several other roles spanning from System Engineer via Application Specialist to Solution Architect, not to mention the roles as Programme Manager, Management Consultant or Business Process Consultant.

My Project Management theoretical background

I started at the university working in groups, where each semester ended with an examination of a project documenting the theoretical knowledge achieved so far. Later through a 10-year period I participated in the Danish version of the PMI education program delivered by DIEU/ Niveau/ Mannaz, first as a Project Manager (4-step program), followed by specific training as IT Project Manager (3-step program).

My Project Management practical experience

Most of my experience is achieved working in a Matrix where the business teams were present in several cities across the country and some across boarders in other regions. Having a physical distance between the end-users and the project team or the team members requires more focus to your communication than when you are present under the same roof.

Except for the years at Telia Networks most projects (or activities) I were given to manage had been or were started as an (only) implementation of new business application, but as it quickly turned out, then a change to existing business processes and organizational roles had to be taken care of, i.e. addressed and handled within the same time frame.

The project teams I have working together with are characterized by having the members present at locations across cities, countries and regions far away from my official office address.

The majority of the daily communication have been by the means of e-mails, phone, conference calls and on-line meetings (Webex), where we shared the screen. I have few times used the video conference tool, however I find this tool less efficient compared to a combination of regular physical team meetings & Webex. When I had the opportunity I have prioritized to visit the team members or representatives of the end-users at their locations, which I believe – with respect to the strategic result – were one of the reasons for the value adding results to the business.

How a project should be defined with a fixed start and finish date

From the PMBOK®:

A project is a temporary endeavour undertaken to create a unique product, service or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exits.

In the event you have a relation between Milestones, i.e. in the “Main Project” and the Sub-projects you could label them like 1, 1.1, 1.2, etc. using 1 as the Milestone in the “Main project”, where you meet with the Steering Committee.

Furthermore, these Milestones can actively be used as references in the communication from the project team to the stakeholders.

General reflections to the operational method

I have over the years experienced several versions of the method used for project management. In general has the company version been inspired by either PMI (PMBOK®) or PRINCE2, however I still find the PROPS Framework for Enterprise Project Management to be the best operational toolbox working with projects – see also my third article.

The PROPS Framework had 4 mandatory documents: “Assignment Specification”, “Project Specification”, “Status Report” and “Final Report” during a project’s lifetime. These four documents were used when communicating with the internal stakeholders. There were many other optional documents within the PROPS Framework, however used for more detailed documentation when required.

Seen from my perspective the most important document was the “Project Specification” being the business agreement between the project manager and the project sponsor. All reporting during the course of the project related to the “Project Specification”, so the risk for scope creeping were minimized.

With reference to the scenarios I have been working with, then I find the other models less flexible – maybe because of a lack of interest in making them more operational, i.e. be more selective in what is mandatory and what is optional.

Organizational Maturity is more important than you believe – also within executing Projects

Having the theoretical model(-s) available for the organization – either as the reference model or as the company modified version – is required when managing projects where the aim is to provide the business with strategic results. The most important part however is the implementation and maintenance of the “project mindset” within the organizational culture.

For companies that want to prioritize the use of projects then I can recommend both to execute an assessment of the Organizational Project Management Maturity and to establish a Project Management Office (PMO) in order to secure a continuous focus on the required actions related to improvements.

The Business Case

One of the topics I have noticed being brought up when discussing the Return of Investment (ROI) is related to (a lack of) the Business Case.

Quote from the Danish CEO of 1Stroke: Martin J. Ernst:

“The business case is solid if the conditions for both the gains that you want out of the project and the efforts needed to realize gains are known, predictable and accepted by all stakeholders.”

When reflecting over all the projects I have been involved in or observed from distance, then I see a point in this quote. In general then the conditions for the efforts needed to realize gains have often been neglected in less mature organizations.

On-site vs virtual meeting during the project life cycle

There are plenty of technical solutions for working together in a virtual team, where Microsoft are aiming for taking the lead with their Microsoft 365 platform. I would however raise a flag here, as technology do not replace the influence the human factor have on turning a project in to a success.

Every team member requires a social relation to the other members that can only be achieved by meeting the team face-to-face. During the small talk in between the project activities each member will share their reality, like the daily priorities given by their line manager or present workload due to an issue related to a former assignment and so forth. This kind of information can be vital for both project manager and team in order to secure the success of the project.

With my experience then I am convinced that face-to-face meetings between the project team members is required at a minimum of once every month. I have once experienced that a team member within 4 weeks after an on-site meeting diverted dramatically from the agreed direction despite several weekly conference calls with the team.

When your project team have been working together for more than a year, then you can switch between visiting each team member at their location, conference calls or gather them at a strategic good location, i.e. customer site, vendor site or a third place easy to access for all. You just have to be aware of the moment you have a fresh resource assigned, then a physical team gathering has to be prioritized.

Next in line

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

In my next article I will share my reflections including my observations related to project management of IT implementation projects.

For now, I wish you a pleasant week – remember to enjoy the time with your family and friends.

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

Image Credits: