Skip to Content

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.

Good luck in your project! Do you have any non-technical rules you’d like to add?

To report this post you need to login first.

17 Comments

You must be Logged on to comment or reply to a post.

    1. John Appleby Post author

      The Run Book is an industry concept that we apply to projects that have cutover activities. It has saved my bacon many times. Bluefin’s upgrade/migration runbook is our secret sauce so I’m not sharing it 😉

      Well pizza is a reference to looking after your peeps. I’ll order you a side salad!

      That’s a great article that stresses a bunch of good things without the industry jargon that accompanies many formally trained project managers. Congrats on getting the project live and I agree that flashy templates and methodologies are nothing without Content.

      I don’t enjoy the role of formal project management, but I have been to PRINCE2 courses and learnt the methodology. I think this is critical to any senior resource on a project because you need a common language.

      For example PRINCE2 defines a Risk as something which could happen and would have an impact on the project, and it has an associated likelihood and impact. An Issue is a Known Risk which actually happened, or something Unknown which happened, and impacts the project. I remember one project where we argued about these definitions. Common language is essential.

      (0) 
  1. Krishna Tangudu

    Excellent “Rules” for SAP HANA Project Managers..
    Would love to be part of this kind of a team and to be “managed” too 🙂

    True things about developers.. And who wouldn’t want a perfect “Sleep” plan and a “Pizza” 🙂

    (0) 
  2. Henricus Bouten

    Your rules made me remember lots of ‘good’ project moments.

    You are spot on with point 7. In many projects the performance is tested for the first time when the systems goes live and when it’s a problem than it is often pushed to the system admins as being a hardware problem.

    As a NetWeaver Technology Consultant I did very often the weekend upgrade or migration stuff and mostly did this is 10 hours shifts. So a sleep plan was in-place and really needed.

    Never had a project manager bring me pizza, but after an troublesome, but in the end successful, all nighter the project manager brought us a nice breakfast with fresh real coffee, croissants and fresh orange juice. That was really appreciated.

    (0) 
  3. D J

    32 HANA projects… wow..

    all these thoughts are equally applicable for any Project Management…It would be great if you could add  stuff specific to HANA from your experience…

    (0) 
  4. Kumar Mayuresh

    Congrats John for 32 HANA projects.


    Though i am not a project manager, but still I learned a lot which somehow I never noticed or no-one made me to think in this way.


    Thanks a lot for guiding Technical and non-technical people.


    Regards

    Kumar 🙂

    (0) 
  5. Henrique Pinto

    At Bluefin we have a top class team around the world – in the US, EMEA and Asia for this,

    Y U NO IN LATIN AMERICA?

    We gotta fix that.

    All in all, these are great tips for any kind of project. I think you added HANA to the title just as a buzzword. 😉

    BTW, did you break the blog title pattern on purpose?

    There were just 8 golden tips, and you created additional two just to baffle me, didn’t you? =)

    (0) 
  6. Aby Jacob

    Thanks John !!

    Appreciate all the advice.

    My takeaway…

    Leadership is about being humble and serving your team and they will respect you for it.

    (0) 
  7. Jon-Paul Boyd

    Now that’s some metric, 32 Hana projects.  Congrats!

    Totally agree with point 3 – simple, clear communications on a single A4 – and have that hanging for anyone from president to team member and end user to see – an open, honest and visible statement.

    Sleep is so under-rated – after 12 hours max I’m useless.  How many times have you seen people trying to be the martyr pushing hours worked when those extra hours don’t deliver a lot of value.  Often I have gone home, slept on it and the solution will be there for breakfast the next morning.

    And a humble manager bringing the brews, croissants and pizza is well respected!

    (0) 
  8. Philipp Nell

    Hi John,

    Thanks for this post. Good summary.

    The points stated here should be valid for all projects, not only for HANA projects, right ? What would you consider specifically for HANA projects like version update frequency or lacks of functionality likely to be delivered in a near future ?

    Cheers, Philipp

    (0) 
  9. Jurgen Lootens

    Hi John,

    Great blog judging by the number of comments. It certainly got my attention.

    On point 1: I think what you are really saying there is that the project manager needs to have a good understanding of the work that is being done by the team. I totally agree with that. The best project managers certainly come from within our industry.

    On point 3: I agree it is important to have a “plan on a page” for the steering committee and a more detailed plan for the team. Again, that’s really not a new idea, but it’s a valid one nevertheless.

    On point 4: Do you mean to say that all expectations should be set in stone at the time of writing the contract, to avoid surprises later? And are you talking about the performance related ones only? I see you have the word metrics in your title, so I’m assuming that’s what you had in mind? You say “measure at every stage/phase”. What phases/stages do your projects go through? Could you elaborate a little?

    On point 5: I don’t think every project needs an ‘impartial advisor’ (it’s not a role I have found in any PM methodology book). Every project needs the right skills mixture to get the job done.

    On point 6: For projects with complex cutovers into live, a run book is indeed essential. But I’m intrigued as to why you feel it needs to be concise? I would say: the more detail, the better?

    On point 7: It would be interesting to read how hard or easy it is to know from the design of a HANA system (ie. before it is built) whether it will meet the customer’s expectations in terms of performance. Can you comment on that?

    On point 8: There is a great book written by Robert C. Martin called The Clean Coder that addresses the issues of estimating, expectations, commitment, saying yes and no, etc. A very worthwile read.

    (0) 
  10. Julie McCarthy

    Excellent summary.

    I’ve always created a living run book for cut-over, and it never ceases to amaze me when organizations argue against it, claiming it takes too much time.

    Your project MAY succeed without the run book, but I want to guarantee that you succeed – and that you are prepared for possible pitfalls.  On one dry run, we had to restore because one five minute step was missed – this seemingly tiny step was flagged in the run book as critical and never missed again.  When one key contributor had a death in the family, the run book steps were available for another to step in.  These things happen.

    I’ve also had to advocate for feeding the team well (seriously?!).  People appreciate that you care about their well being.  Feed the team and keep them together.  They deserve your care and respect.

    (0) 

Leave a Reply