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.
