Sunday, 9 November 2014

10 Golden Rules for SAP HANA Project Managers

SAP HANA Training Videos
One of the things I do in my day job is to oversee the HANA projects that we have going on. I usually provide some advice at the beginning, have a QA role and if the project needs a little help at critical points, I'll get stuck in. I've done this on all the 32 HANA projects we had going on over the last year and so I've got a few battle scars. I thought I'd share my experiences, which relate to any SAP upgrade or migration project but which are particularly important for SAP HANA Migrations.

Why are they particularly important? Well, businesses have high expectations of HANA and it's not just a "database" shift to the business. They have been promised amazing things, and it is important that you setup the project to succeed. Here are my rules.

1) Governance is by far the most important thing

I learnt everything I know about this from master project manager Kiran Patel. When Kiran is managing the project, I don't even need to check on anything. With a good project manager, you can have bad infrastructure, business delays, a flood or even bad technical resources. They will ensure that the business is kept in check, timelines are assured and acts of god are avoided. OK, maybe not the act of god. They will get the right resource model both with the business, customer IT and third party suppliers and manage the relationship between customer, SAP and consulting.


They will also know the rest of this list. It is critical that either your project manager, or someone that the project manager has access to (often the role that I play) have previous experience of upgrades/migrations. There is specific language to learn and specific things that can go wrong. A project manager managing a migration for the first time is likely to fail.

2) Separate out project communications and business communications

Normally this is done by separating the project leadership team from the steering group. This is important because it creates a firewall between the business and the project team and allows the business to be specifically informed on how the project is going and what the major blockers are. If you don't do this then the internal IT team will often mask things from the business, and there is a risk that bad decisions will be made.

I had a situation some years back where a customer refused to listen to our advice. We documented it, they agreed to take responsibility for any side-effects (which they claimed did not represent a risk), created an exception and when the project went wrong and we lost 2 weeks of time, we created a change request. The client-side team refused the change request but when the steering group met, this was clearly explained to them and they approved the change request without delay.

3) Create full project plans at the right level of detail, with specific timings

I hate long project plans because they are hard to read, and I refuse to install MS Project on my machine (I'm not a project manager!). So I want to see a high level project plan which shows week by week activities and commitments and allows you to see how you are in the macro scheme of things. This is the plan you should use communicating with the steering group. It should fit on one page of A4 and anyone should be able to understand it.

Then you need a detailed project plan, which lists individual tasks. I like one line to take 1-6 hours to complete and be at a level that a project team can understand. It should make things like the steps of an upgrade (pre, main, post) separate and separate actions in different teams like upgrade, backup etc. But don't do too much detail - the project manager should be able to say "did you do this?" and understand the response.

4) Build in metrics and success criteria, and measure them at every stage

This is important for any project and critical for a HANA project. What did the sales team promise to the business? The business team will have an implicit set of expectations from the sales process, and you have to deal with this. The way you do this is to ask them for their implicit expectations, and turn them into an explicit set of expectations.

What process, what data load, what report? What timings, what change in look and feel? Document these, push back and try to get them reduced, and get the business to sign off on them as success criteria. Make sure they are empirically measurable. And now measure them - before project start, and at each phase. Analyze the risk of not meeting expectations and add additional work to tune systems if necessary.

I had one project where the business had a set of expectations and the project was long and complex (6-7 months). We knew that we couldn't meet the expectations with the project alone, and we noted there were a set of infrastructure changes coming with the project. So what we did was to synchronize the improvements with the go-live by making sure that the system didn't get slowly faster month after month, but rather we got all the improvements in one go at go-live.

5) Ensure you have an impartial advisor on the project

This is the role that I usually play on a project. This allows the project to be set up to succeed and to push the team to do things the "right" way in the first place. It's important that they know enough about the project to see the major risks, and advise the project team. In addition, and this is super-important, the project manager can call them in at short notice at critical times to make decisions.

For instance, I have been involved in a project where there were unexpected infrastructure problems and the project team had been working for 18 hours and was exhausted and was making mistakes. I calculated the time to restore versus the time to continue, analyzed the risk, and pulled the go-live. The project team was emotionally involved and couldn't have made that decision for themselves, but it was the right call. We took the time to understand the problem, got some sleep, regrouped and went successfully live two weeks later.

6) Create a living Run Book, review and revise it at every stage

I am a big believer in the run book, and different people do it different ways. I try to make it as concise as possible, without missing information. It must never miss steps because they are too small or "assumed". It should allow a sick project member to drop out at the last minute and be replaced by an expert who hasn't been involved (key that you use an expert in this situation) and it should allow an additional member to join the project if there are delays and you need to shift the team to work 24/7.

I've had both of those situations happen many times and I'm always relieved when I see a good run book. But remember to get the book reviewed by your impartial advisor because they will be critical. Both the content and the style of the book matter. Also make sure that if you hit an issue on a dry run, you mark a big red X on the run book and figure out what that issue was, and modify the run book. It is a living document.

7) Deal with performance by design, and early

My first ever serious SAP escalation was on the first BW 7.0 Integrated Planning Project back in 2006-2007. The project had signed up to 5-10 second response times and we were up at 5 minutes for individual planning steps. The project team hadn't understood the impact of having the wrong infrastructure (Sun T2000) and not dealing with production data volumes during the design phase.

By the time I got involved it was late in the day and we had to make some fast and drastic changes. We re-platformed to Sun X4600, patched the system, installed a bunch of performance fixes for the SAP code, optimized the application and rewrote a lot of code. The performance problems weren't just in one place - they were everywhere. We also negotiated with the business and reset the expectations on performance to 10-20 seconds, which we met.

Design performance into your project from day one.

8) Don't trust your team when they are under pressure

If you ask the team how long something will take, you won't get the right answer. So you need to physically measure how long each step in the project plan takes and put that into your timeline. If it takes too long, find out why, and rerun the step and update the run book and timeline.

If you ask the team how it is going, they will say "OK" until it is too late. So you need to specifically find out where they are compared to the plan and document that against the timeline.

If the timing slips and you ask the team what happened, they will often try to baffle you with technology speak. So you need to coax them to talk in your language, which is plan vs actual, and understand what slipped, how you will change it in the next run, and how to update the run book.

It doesn't matter how senior your team is, this is human nature.

9) Create a sleep plan, and stick to it

I don't know how many projects I've been brought into where the whole project team has been working on it for 18 hours, they are tired, making mistakes and don't want to be helped because there's "just 5 minutes left". There is never just 5 minutes left!

So it is the project manager's job to create a sleep plan and rotation. The rule of thumb is that technical resources start making mistakes after 12 hours. They are usually useless after around 18 hours and need 9 hours to refresh. You need to look at your team and understand what their dynamic is and plan sleep and rest accordingly.

At Bluefin we have a top class team around the world - in the US, EMEA and Asia for this, and I split the work into 8 hour segments and follow the sun. For critical tasks we wake the local team so they can do the things we are most familiar with. But the important thing is that tired people make bad decisions.

10) You need to deliver the pizza and bring the coffee

I'm a huge believer that leadership is 10% strategy and 90% carrying the water. This doesn't mean that you should undermine your team, or micromanage - though it is often necessary to micromanage during parts of a project, as you will see from the above points.

What it means is that your team have to know that their leadership team is invested. If you're the lead for the customer or project, or even the CIO, you need to be there and you need to buy the pizza and make the coffee. Leadership is about being humble and serving your team and they will respect you for it.

Final Words

I have a bunch of technical advice too, but I wanted to separate it out into a separate article because this one is getting too long and this feels relevant as it is. These rules have served me well for scores of successful SAP projects and I hope they serve you well.

No comments:

Post a Comment