Remote Project Management & New Methodologies Usage

Does the current situation restrict us from practicing project management?

Do SAP (or any other IT) projects need to hold and wait until the situation changes? 

This question is the most frequent one being asked these days in our business. Especially in light of the fact SAP projects are, anyhow, very massive, complicated, risky and expensive projects.  

In this article I will use SAP implementation projects as test case, but the idea is quite the same for all sorts of IT projects and even some of the non-IT projects. 

The known methodologies and practices are the project manager's shield for minimizing the risks and increasing the chances of having a proper project with a secured Go Live.

The current situation is a very non-methodological situation, therefore we all need to adopt ourselves to some critical changes:

Work from home - 

Work from home is a mandatory change due to the COVID19 situation and the governmental restrictions that are being dictated to us all nowadays. The key challenge here is how can one manage his project, self-activities and tasks, makes great sure people's commitment stays high and keeping effectiveness of meetings, decisions and time lines intact.

In fact, the last two months taught us a very important lesson about the effectiveness of working from home. Putting aside the problem of kids running next to you, the personal effectiveness of a worker is higher from home than from the office due to the following reasons:

• Travel time to the office - the workday starts without travel time, traffic and aggravation. The worker can start his morning in time for the first meeting or activity, being more relaxed and therefor more effective. An 8 hours day is really an 8 hours day.

• Travel time between countries - no flights means less time and money wasted. The worker provides you 100% effectiveness during his working days. One can say that the digital revolution is the evolvement of the globalization revolution.

• No coffee breaks - for sure the employee will take some breaks during his day, but he will have much less time wasted on cafeteria discussions.

• Easier and quicker response time for personal and home issues will clear more time for work related tasks

Methodological agility - 

There is a very common and clear way of performing SAP projects. In the past few years the methodology extremely evolved into the Agile approaches direction. SAP methodology is being affected by remote working in several points:

• Design phase - in the old waterfall methodology the design was performed in a very simple way. The consultant was using whiteboard and PowerPoint decks designing the new processes while interviewing the customer business representatives for their requirements. Then he went home to write the blueprints, which were usually very high leveled and provided a lot of misunderstandings and conflicts later on. The new methodology is built on the approach that SAP is not a development environment. SAP provides it's customers Best Practices to demonstrate how the business processes should look like in a common company. These Best Practices are being divided to verticals by industries in which SAP has years of experience and deep processes knowledge. Moreover, SAP provides pre-configured reference system as a backbone for the design phase. Taking this into account, we should not refer to this phase as design or blueprinting phase anymore but as Fit\Gap analysis phase between the requirements and SAP's Best Practices. Utilizing the reference system provide the customer the knowledge and confidence in SAP's processes and reduce one of the most critical risks in this kind of projects - the change management. In the world of remote projects this phase is totally doable due to the usage of video conferencing and screen sharing. 

• Build phase - this phase suffers the biggest change due to the new methodologies - in the past, this was the "easy" part of the project. The project team were building the system by themselves, maybe showing some developments as "validation sessions" and do the delivery testing by themselves. This part was identified as one of the biggest mistakes in projects. It was increasing the risk of mistakes, re-work and change management issues. Therefore, the change of it was very much needed. In the Agile approach, the build activities (configurations & developments) are being divided to sprints. Every sprint takes 3-6 weeks and hold the full project lifecycle of designing, building, testing and presenting to the customer. In this method the customer is much more involved in the process and nothing is being kept to the testing phase when the customer might be disappointed of the results. It increases the belief of the customer in the system and the process as he sees it being built in front of him and feels a part of it. Probably one would say that this change is a problem due to remote working, and the old way was more relevant for it. I argue differently. I think that the VC tools provide us with almost the same quality of validation and verification meetings.

• Testing phase can also be done remotely an easier way. Since many consulting companies are utilizing offshore centers, they are very familiar with the method remote testing. The challenge is how to do UAT (User Acceptance Testing) from distance, which is also doable. The only implication here is on the timelines. At this stage users are not educated enough to run the test scripts by themselves. Usually the consultants are there with them, holding their hand while performing the tests. In our case the "hand holding" should take place from a distance and it takes longer time. In a typical project, adding one month to the UAT will solve this risk and provide the same results in the end.

• Deployment phase - is the tricky part. During the deployment phase there are three main activities that need to take place: trainings, simulating the Go Live (dress rehearsal) & cutover. We can utilize new tools and approaches in order to train the people. In most cases it will work. We can simulate in remote and it probably will provide the same results, But we cannot Go Live in remote. Even in the case of a company, which is running its business in a fully remote approach, the risk of Go Live errors and the relatively slow SLA of correcting them in remote is too much of a risk in a project that is replacing the company's digital backbone. At this stage, as far as I know, no promising solution to this problem has being introduced. It doesn't mean we will not find one. It will just take longer time.

Global vs. local - 

Many global companies are taking the global template approach in order to distribute their system. The main problem in this approach is that the deployment team is usually part of the Global organization or even one of its specific subsidiary. The problem is that the team is pushing all deployments to the direction of the first one. It causes even more unneeded painful process for the subsidiaries and generate a larger risk.

By remote working you can build a real global deployment team that can be assembled from many countries and work effectively on larger scale of locations and subsidiaries at once. 

Cost effectiveness - 

One of the largest expenses in ERP projects (especially in global ones) is the travel cost. In this new non-traveling world, we can save this money and invest it in better solutions or longer testing period and change management activities.

To summarize it all, the current situation we are adopting to should not stop the business. Projects can continue running with several needed adaptions. 

Moreover, we can find a lot of usage to the new work methods and save a lot of time and money. 

With the hope of sooner than later lockdown release, the Go Live problem will solve itself as regular times come back. If not, I'm sure we will figure it out.