Skip to Content

Successful Projects Need Excellent Coaches

I have seen many successful development projects and some failures. One very dangerous thing for a project to do is not to enlist an excellent coach or champion to help the regular project staff with new technologies.

There’s always something new to tackle

With innovation cycles getting shorter and shorter, few projects can be handled completely within the project team’s comfort zone. There’s always something very big, very new to tackle: a new release of the server and/or IDE, a new user interface technology such as Web Dynpro or Adobe Flex, new tools such as NetWeaver BPM or BRFplus, newly implemented standards for web service authorization, and so on – the list of what NetWeaver-based project teams are currenty facing could go on and on.

It’s okay to be inexperienced

Clearly, with much of the things you’re working with being new or at least recently updated, it’s okay to be out of your comfort zone. Of course it helps to have a few software veterans on board who have demonstrated the skill to find their way into any new matter very quickly, but even they will occasionally be out of their depth when working with new tools and programming techniques.

Blessing and curse

The new stuff is both a blessing and a curse. On the one hand, your project team may be eager to adopt state-of-the-art technologies and concepts. (Consider yourself lucky if they do!) The new tools were probably designed to save you a lot of manual labour and will do just that if properly employed. Developing everything you have ever dreamt of will be a breeze!

On the other hand, best practices may not yet exist or be available for the new stuff, and your project team has little or no relevant experience to make up for the lack of publicly available best practices. The tools may still be buggy, and both documentation and community knowledge such as wikis or forums will be sparse. Combined, these risks can slow down your project significantly and even bring development to a halt.

Risk control

Fortunately, these risks are very well manageable and the potential problems are avoidable. There are a number of things you can do to control the risks. Frequently, the only thing project managers can think of is to spend a lot of money on classroom training, which turns out useless in many cases. So what else can you do?

Teach your staff how to handle errors

  • Make sure your developers know how to search the available sources for information: SAP Library, locally installed help, docuPedia, SCN blogs, forums, and wiki, OSS (SAPnet) notes, possibly an internal wiki, SAP Press books, and other resources.
  • Make sure your developers post their questions on the SCN forums early enough. Everybody should know how to describe the problem and where to post the question. If the error is resolved, no matter how, the solution should always be added to the forum thread.
  • Don’t let your project staff chase the same bug for days in a row. Establish procedures to prevent a clueless person from being stuck for days by escalating the bug hunt quickly – for example, “after 5 hours, escalate to the most experienced programmer”.
  • Teach your Basis stuff to look for new Support Packages regularly. Don’t get too far behind because if you request SAP’s support you will be asked to install the latest SPs anyway. Updating your system regularly will help you save time when it’s critical.
  • The most experienced person on your team should be authorized to create OSS notes if all else fails.

These measures will solve 95% of your problems.

And the last 5%?

Implementing these matters will help a lot, but what about the final 95%? What about best practices, which are frequently hard to find? What about the problems in your own code that noone has been able to locate, let alone resolve? What about the occasions when you see a number of possible directions you could go into but you have no idea which one is right and which one will lead to a slow and painful death?

Only an excellent coach can help with that.

Fig. 1: Coach

No compromise: You need a great coach

  • You absolutely need a person who is highly experienced with exactly the things you are working with: Not with the previous release. Not with a neighboring application – find someone who has exactly the knowledge that you need.
  • The coach should be well ahead of the project team and should learn constantly so as to remain so.
  • The coach should be a good communicator. Teaching is their main job, programming is only the second priority.
  • Your coach must be well-connected. Frequently, they will be confronted with detail problems in areas where they have little experience. Having a few good people to use as “telephone jokers” is a valuable asset that an excellent coach should possess.

How much do you need?

Of course you can’t staff your entire project with top champions. They are expensive and hard to find – you’re lucky if you can get your hands on one top coach. So how much do you need? That’s hard to know exactly in advance and depends on the particular project, but here are a few hints:

  • Programmers faced with a challenging new environment need to catch up with a real expert once per week, at the very least once every two weeks.
  • Ten to thirty percents of the work in a challenging development project require a top expert.
  • The more inexperienced people work on your project, the more time is required to review their work and provide guidance. I’d say it takes one experienced person to keep track of the work of six newbies.

These rules of thumbs may turn out useful in determining how much assistance you require and which modus operandi you will use for working with them. In a larger project, you may be able to get one or two top experts to be permanently on site, while in other projects you may arrange for bi-weekly jour fixes or a few spot consulting days to be booked on short notice.

“It costs money because it saves money”

Who could forget the immortal words of Cosmo Castorini in the movie “Moonstruck” with Cher and Nicholas Cage:

“There are three kinds of pipe. There’s aluminum, which is garbage. There’s bronze, which is pretty good, unless something goes wrong. And something always goes wrong. Then, there’s copper, which is the only pipe I use. It costs money. It costs money because it saves money.”

Fig. 2: Cosmo Castorini

Some project managers may dread the costs of hiring a champion who costs 50% to 100% more than a regular staffer on the project. They’d rather add a few more newbies and hope that two or three newbies make up for one top expert. That is utterly wrong.

The coach is the person who solves the problem which will otherwise keep an entire project team idle for several days. The coach is the person who shows ten people how to perform a standard task (which will be repeated many times) in half the time. The coach prevents the project from wandering off into dead alleys by providing guidance throughout its course.

Yes, coaches cost money. They cost money because they save money. So if you haven’t recruited one for your project, go ahead and do it now.

You must be Logged on to comment or reply to a post.
  • Hi Torsten,

    this is a great blog. I fully agree with your arguments. Love the quote from “Moonstruck”, but I am a bit puzzled about the analogy between the basketball team in Fig. 1 and a regular project team 🙂


    • Hi Björn-Henrik,
      Thanks a lot. I've always loved that quote and I'm happy I found an excuse to put it into a blog. 🙂 But what's so puzzling about the project team as a sports team? Would you have found an image of two duelists more fitting to represent the collaboration structures in projects? (Just kidding.)
  • Seems like I'm a very similar situation as you are: X(X)L Composite, mixed skill levels, etc. (we even have a distributed development team).

    Yes, coaching is really important! More so is empowering, let the team learn, let them grow.... challenge them 🙂

    Here's an extract of what I wrote to my dev team:


    This project is definitely quite challenging and in order to get us to the next level we would need to continue to push hard individually, each other and as a team as a whole. [...]

    Within a team, there's always a first roster indicating who starts the game and is on court during prime-time/overtime to score the big points. During this time, the key players/go-to guys are usually stepping up to score the big/important points. However, it frequently happens that someone from the 2nd roster turns into this go-to guy in particular games and initiates the turn-around. In order to get a team as a whole to reach its maximum potential you constantly want the team members to challenge/push each other...

    Usually, this is a natural process that evolves and makes a bunch of people a team that share a common goal. Individual time on court is NOT the most important thing... winning the game is! So, if a key-player has a weak day, someone needs to step up and claim that spot/position (=claiming the challenge). And so it goes...

    [...] Please note that it's free to everyone to propose new challenges. In order to keep it an even-playing field we will issue both specific and open challenges that can be accepted by anyone - if multiple people claim it- those with the least amount of accomplished challenges take precedence. Ultimately, we would all end with up to 5 accepted and accomplished challenges...

    Now, let me be clear... a challenge is just a challenge. An opportunity.... nothing more/nothing less. It's a chance for the contender(s) to grow/learn and at the same time push our common goal. So to speak it will be things outside of your daily activities/responsibilities - and something that is beneficial for the team.


    Oh, and here's the definition of the concept of challenges we introduced in our current project:

    A challenge is supposed to be challenging (who would have guessed?) and to motivate people to strive for excellence and new learning individually in order to accomplish something in best interest for the team and its goal at the same time. Typically, challenges will fall in a cross-disciplin area outside of your primary domain or component/role in the project. However, very ambitious challenges may even be within your primary domain/role, yet are very important to be done at a specific timeline or extra-ordinary quality for the benefit of the team. As challenges may require you to spend effort in addition to your scheduled tasks I would want to keep track of such extraordinary achievements - for bragging rights/for the great feeling of having done something extra to contribute to our common goal.

    • Wow, your notion of institutionalized challenges - including official bragging rights 🙂 - is very cool (and in fact inspiring). I'll show that to a few colleagues and we'll discuss ripping off the idea.
      Thanks a lot for sharing. 🙂
  • Lots of relevant points that I agree with.  I think what some customers need to understand is that they don't need the coach 100% of the time.  They're obviously concerned to some degree about spending money for a resource that they most likely perceive as a luxury.  But if they just get a day a week or 1 week a month from some one that good, it will pay off big time.  You don't always need a coach to be there daily to do a lot of hands-on work or status meetings.


      • So this should open up a new model in consulting - or may be it is already there in some form. For a retainer fee - a customer could get a certain number of hours in a month from a top SAP expert.

        The only question is - how many such experts will be needed for a big SAP footprint at a customer. No one knows it all.

        And unless you have a bunch of superstars in your organization as employees, it is kind of hard to get an independent to just come for a one-day-a-month type thing.

        I have to think through this - it is an interesting idea. Isn't this along the lines of what the vivido labs guys offer?

        • I think we've had this discussion before, but it's difficult to staff this type of requirement.  I've done it but never for anything longer than a 2 month assignment (50% involvement) because the logistics and transitioning to other projects were too difficult. 

          The number is debatable.  For an initial BI or ERP implementation you need your most senior resources 100% of the time.  I don't think you can use this model then.  But for a 2nd or 3rd rollout?  Probably that would be the time to work in a senior resource who had to oversee a growing staff that is starting to work their way up the SAP knowledge curve.


  • Hi Thornsten,

    Besides a very nice blog, this is also very nice reference material that will help to argue the case when a project manager has selected a complete legion of junior project members, but no one to mentor them. It's good to be backed-up by an external authority who has taken the effort of putting things in writing 😉

    I'm thinking of printing this out, framing it and putting it on my future project managers' desks 😉 Thanks a lot for putting this down so concisely.


    • Hi Jan,
      Thanks a lot for your feedback. It's good to know that others sit in the same boat and I hope I've made a tiny contribution to your next project. 🙂 Maybe I should print out a copy with "Jan Penninkhof" as the author and put it on my own PMs' desks. 😉
  • Hey... Great Article. Reading it brought tears to my eyes. Every word of what you say is very very true.

    hmmm..... I am just wondering why no comments from anyone in India. ( This is just a thought..... not intended to hurt anyone. ) 🙂

    • Mazin,
      Thank you for your feedback! Regarding your question about India - I have no idea because I have no experience with project culture in India. What is it like?
    • What is your point, exactly? How does this relate to "any one from India"?

      I am glad you clarified it is not meant to hurt any one = so I am not hurt reading your comment. But still very curious on why you were wondering that no one from India posted a comment. I did not see a comment from most of the other 100 plus countries in the world just confused.

      Hey Thorsten - great blog as always. Nicely done.

      • When I read the comment and checked the country flag of the person posting, I saw an Indian Flag, so I must say I was just as puzzled as Vijay but perhaps for a different reason. I wonder, do we sometimes engage in bashing our fellow countrymen(women) as some preventative or defensive mechanism?  As a community advocate, of all community members, I must say I wasn't overly pleased to read the comment and I commend Thorsten for not rising to the bait.
        • Hi Marilyn, Vijay

          Sorry if I hurt any feelings. My intentions were not against anyone. Its just that I felt that we need more contributions from India in the Blogs and other areas of SCN as well. ( Not just the forums where I see countless numbers of Newbies posting basic questions )

          I feel that there should be a lot of thought which has to go to the process of project management which are sometimes taken too lightly. Projects are not about just putting more men on the Job and writing code. I feel that many startup companies are doing just that. If not thought out properly, implementing an SAP project could be disastrous for everyone - the consultants, clients and the consulting firm.

          Once again, I apologize if my comment was offensive to anyone. Moderators may remove it if its not appropriate. Sorry for the trouble caused.

          Best Regards,

  • Thorsten you are brilliant.  No surprise that your blog garners so many comments and resonates so beautifully with so many folks.  Besides it incredibly accurate depiction of project challenges and resource solutions it also triggers a thought that if others began a blog around a quote they loved and always looked for a chance to use (in an SAP context) we would have the makings of some very useful content.
    You started us off with “It costs money because it saves money”
    Any other takers?  Now who said, if you aren't part of the solution you are part of the problem?
    • W00t - I want to see an entire series of Godfather-inspired SCN blogs.
      "Sergio. Your consulting firm has always provided good and loyal services to my consulting firm. ..."
      "Mr. Jung is a man who insists on hearing bad news immediately."
      Or remember the Macchiavelli-reading gangster Sonny (played by Chazz Palmentieri) in Robert DeNiro's "A Bronx Tale", in response to a little boy's question: "Is it better to be loved or feared?" - "That's a good question. It's nice to be both, but it's difficult. But if I had my choice... I would rather be feared. Fear lasts longer than love." Inspiring, isn't it?
  • Hi Thorsten, great blog! It all really makes sense.

    All except the 2nd sentence, which says "One very dangerous thing for a project to do is to enlist an excellent coach or champion to help the regular project staff with new technologies."

    Don't you mean "One very helpful thing for a project to do ..."?

    Or maybe "One very dangerous thing for a project to do is NOT to enlist an excellent coach ..."?

    Otherwise you're warning people against the same thing you're recommending.

    Best, --Richard

    • Richard,
      Thank you very much for pointing this out to me - it is indeed a typo which I will correct along with a few others tomorrow morning. 🙂
      • A typo?  I'm disappointed.  I thought it was a brain-teaser.  As in first I'm going to challenge you by telling you what not to do, and then I'm going to tell you exactly how to do it.
        Like: "Don't open the fridge where I have a 7-layer cake with fresh thick frosting and stick your finger in the edge to lick some"
  • Hi Thorsten,

    Excellent post, again! Being a coach (or mentor) is your second nature.

    Projects have teams to accomplish things.
    TEAM = Together Each Achieves More

    And of course teams need coaches, which for sure is something different than project managers. I am not saying that project managers are not required but it is a different role.

    If you want your project to be successful, make sure that your team is in balance:
    - Experts versus newbies
    - Vision versus day-to-day business
    - Business versus IT
    - Soft skills versus hard skills
    - (Solution) Architects versus consultants

    A coach facilitates, explains vision, fits solution into architecture, identifies risks and takes appropriate action. Great role, a coach builds a team out of individuals!

    Kind regards