How an Agile Tool Got Me A Project Management Role

Here is the second part of my journey on becoming a Targetprocess advocate.

What is Targetprocess?

Targetprocess is a visual platform to help you adopt and scale agile across your enterprise. You can implement your own framework or use existing ones to achieve business agility and see the value flow through the entire organization.

Recap from Part 1:

I had just quit my previous job because I wanted to be a Project Manager, and wanted to see how it would feel to implement Targetprocess at company level.

Methodologies, Processes and Tools Specialist

My initial role at my new company (let’s call it Company B) was that of a ‘Methodologies, Processes and Tools Specialist’, attached to the Project Management Department. That meant I was in charge of helping the company understand and adopt new tools and methodologies, on its journey towards agility.

A word about agility here. SAP had so far been using Accelerated SAP (ASAP), a waterfall methodology, to implement its softwares. Company B had been using ASAP on its projects, with varying degrees of success. However, the IT market was far along its transition to agile methodologies. SAP introduced a methodology, ‘Activate’, in order to capitalize on the trend.

Waterfall? Agile?

Waterfall is the traditional way of doing projects. The consulting team understands the situation, writes a blueprint, estimates the work, gets budget approval and drafts a project plan. Then the Project Manager executes the plan, trying to reach all those milestones on time, on budget, and deviate as less as possible from the requirements.

The problem with waterfall is this adherence to the plan: if for some reason (new market opportunity, new law, new employees requirements) you need to change something about the project, it can be tough. Change Requests need to be created and approved. The process can be very slow. Change is to be avoided.

Another problem is that, often, the customer doesn’t get a chance to inspect the product before most of the work is done. Changes made earlier in a project are cheap. But as you get close to the finish line, making changes becomes very costly.

Agile was introduced because softwares don’t need to be implemented using waterfall. Waterfall is great when building a house, not a website. Waterfall is great when the project is about something known, done before. Not when the unknowns abound (as they often do in I.T.).

Agile is based on flexibility, collaboration and feedback loops. Fail early: build a prototype of the product, collect feedback, adapt, add functionalities incrementally. At any time, it is possible to stop the project and still have a working increment of the product.

SAP Activate Methodology

Agile has many flavors: Scrum, Spotify (yes, the music app has its own methodology), Less…

SAP took the most common flavor of Agile, Scrum, and adapted it to its products by adding a detailed framework and project deliverables. Consequently, as a certified Scrum Master, I had a head start at Company B on becoming a SAP Activate Expert.

My initial task had two aspects: understanding Activate, but also help the company select a tool to manage its projects, in accordance with this new methodology.

I started working on a proof of concept with my Manager, and quickly understood it would be challenging. My boss was very well versed in project management. An expert… in waterfall. He wanted Targetprocess to give him the same KPIs (Key Performance Indicators) he had been relying on for the past 20 years: Estimates at Completion, Cost Performance Index....

Targetprocess is an agile tool, for agile project management. The concepts are totally different. We won’t be digging too much into agile in this entry, but suffice to say that there was no way to get the KPIs he expected.

As long as the management didn’t understand the fundamental differences between waterfall (where you focus on eliminating deviations to the plan) and agile (where you welcome change as an opportunity to deliver value), it looked like Targetprocess adoption would not be a thing…

Trial and Error

Transition to agile is a necessity, and was a priority of Company B at the time. My manager’s bosses wanted to see results. So despite his reluctance to use a tool that didn’t match his expectations, my manager gave me an approval for a real situation test.

I was assigned to work with a Project Manager whose project would serve as a prototype in Targetprocess. When nominated, that person indicated she was really excited to have been chosen, and couldn’t wait to start. However, when I got in touch to start thinking together about how we could build the tool, I was told 2 things:

• The project hadn’t really started yet, so there isn’t much information yet to process

• I could work directly with the senior consultant on the projet to get what I needed

Here is the problem: we are trying to build a tool that will give Company B an edge in managing its projects. That tool needed to be built collectively, and suit the needs of every stakeholder (customers, consultants, managers, partners). I was not building a tool for the management to get reports, or for the project manager to track the work… I was trying to build a tool that everyone could rely on to get the job done more effectively. I needed everyone collaboration.

We were not there yet.

Trial and Success

During my time working on this initial prototype, I was approached by a young Project Manager who was really excited about the whole thing. Despite not being part of the initial initiative, he asked me if one of his projects could be used to experiment. He was encountering challenges that he thought the right tool could help alleviate.

Manager M. was pivotal in the adoption of Targetprocess at company B. He had very specific requirements, provided a lot of feedback, invited senior consultants to meetings in order to understand what they needed to use the tool, asked customers to participate and provide feedback. After a few weeks working with him and his project team, I had something that could work.

Manager M. didn’t hesitate to make the use of Targetprocess mandatory for his project. He would ask consultants to make sure to update their tasks, and would often contact me with things that needed to be corrected or created.

Over the 6 months period that I worked with Manager M, I progressed tremendously, and by the time his project was live, Targetprocess was already a success.

A Question of Opportunity

Around the time that I had a working prototype of Targetprocess in my hands, thanks to Manager M, an unexpected opportunity presented itself.

One of my colleagues, a Senior Director who had quit Company A for Company B, like me, and happened to be a friend of mine, was asked to lead a proof of concept for an implementation project. The customer was reluctant to sign, and needed evidence on our competence with the software, as well as a demonstration of our implementation methodology.

Director F. was not interested in Project Management and knew about my long term goals, as well as my knowledge of methodologies and tools. He offered to have me as a Project Controller, to assist him. In reality, I would be in charge of everything project management.

I dove into this without a second thought:

• I prepared a Kick-off deck heavy in methodology (activate) and tools (targetprocess)

• I configured the tool in advance of the project start

This proved to be the turning point in Targetprocess adoption. The proof of concept was small enough (5 consultants over a 5 weeks period) to quickly go over all phases of a project and show results. Customer resources participating to the proof of concept were equally just the right number (about 5) and strongly motivated, which meant they used the tool as much as the consultants. Collaboration, constant visibility on project items, communication, reporting… all aspect of a normal project were greatly enhanced.

Before the proof of concept ended, the customer indicated they could not wait to start the project. They cited Targetprocess as one of the highlights of the experience. And they specifically requested to have Director F on the project, as a Solution Expert, and me… As the Project Manager.

Nobody saw that coming.

What happens next?

I am now the Project Manager of a multi million dollar project, with 20 consultants assigned to it, and 30 resources on the customer side. A very critical transformation initiative, for both the customer and the consulting company that employs me.

Challenge accepted.

Did I succeed ? The story will continue in a future blog entry :)

Spoiler: I have extensive experience leading SAP Projects.