After you have done all of the hard work, selected the vendor, and started on the blueprint path, you have one more low-risk opportunity to ensure breakthrough project success. Keep in mind here that this area of the project involves more risk than in the previous stages, because the other ones were fully under your control. You could directly mitigate the risk, you could decide against contracting with a particular vendor, and you could simply back away from anything up to the selected vendor beginning the project.
Now that you have selected the vendor, you have one more opportunity before you incur huge costs to ensure that you are getting what you pay for: the blueprint phase.
Keep in mind that during or at the end of the blueprint phase of the project, you face risks if you change out problem or underperforming consultants. Additionally, the size of the team covering a particular area can compound said risks (for example, a smaller team covering a single SAP module like SD, MM, PP, FI, CO, etc., carries higher risk than a larger team covering a single module). If everything goes well up to this point, then the reason you may end up replacing a consultant will likely be personality and team dynamics rather than a lack of skill. While you can work through personality and dynamics to a certain extent, a lack of skill is dangerous to your entire project. As a result, if there is a risk to replacing consultants during or at the end of the blueprint phase, it may still be your best course over the longer term of the project.
You may wish to define with the selected vendor in advance how they would mitigate the risk of replacing one or more consultants during or at the end of the blueprint phase of the project. This way, you both set the expectation in advance and force them to consider how they would take care of this potential problem. You also ensure that the right tone for quality and results are set throughout the project. After all, this is your last chance to ensure that the vendor resources are the right fit.
-
- A proper blueprint must contain the details of the how the functionality will be implemented, not what will be implemented. The what of the blueprint is the scope. You wouldn’t consider a home plan a blueprint if it only included an exterior elevation and a few artists’ renderings of the interior, would you? If the home plan didn’t have the foundation details, roof details, electrical, framing, HVAC, etc., you wouldn’t consider it a blueprint at all. If your vendor-provided blueprint document doesn’t contain the translation of the business requirements into the how of the functionality, then it is not a blueprint. It is simply glorified scope.
-
- Ensure the implementation vendor provides a Blueprint Template on day one of the blueprint phase. Ask for examples of prior blueprints as part of the proposal (scrubbed of the client name if they wish). If the vendor does not provide actual samples with significant setup details, disqualify them.
-
- Pay close attention during the start of the Blueprint to find out whether the consultant has any idea of what meetings to schedule, what key company individuals (by job/role) need to be in those meetings, or what topics to discuss during said meetings. This is a huge indicator of whether the consultant has experience.
-
- Be sure to sit in on the first few requirements gathering sessions for every consultant. If they seem clueless, they probably are. You might want to consider an immediate change before you invest in a mess.
-
- If you are a large enough company that you have more than one consultant assigned to a module, you should insist that you observe requirements gathering sessions with every consultant.
-
- Unless they have been clearly noted as juniors or otherwise made clear to you as the paying customer they are inexperienced, companies should never pay outrageous rates for inexperienced but “smart” folks. Just to ensure that more senior consultants aren’t covering for them, you might want to insist that they lead their own requirements gathering sessions while the more senior consultants are doing other work.
-
- Create a blueprint project requirement that every single module must complete at least one entire process string, start to finish, for a simple process area. This should include basic organization structure requirements and should be completed in less than two weeks after the first meeting (a really good consultant can do an entire process first pass and in a week, including all documentation and requirements). At this checkpoint, you can evaluate the quality of the consultants that the system integrator has brought to your project. If you find that a consultant was unable to accomplish the task, or if their process blueprint documentation fails to describe how it will be done in SAP, then I would seriously consider asking the integrator to remove this consultant from the project. Better to do it now and possibly hurt a little of the blueprint timeline. Alternatively, this person can possibly slow down the whole project, or make a mess out of the system design, setup, and testing, and then possibly blow the budget and timeline. Even if they don’t blow the budget and timeline, and even if they don’t make a mess out of the project, why do you want to pay that integrator such a premium price for some junior resource that will not add any value to your business? If that is what you want, promote from within! It is cheaper and creates more visible opportunity within your own company. You don’t need highly paid dead weight on your project.
- Insist that they perform a prototype of the simple process they defined within four to six weeks of the blueprint start. No matter how big, complex, or far flung your company is, there is no reason that a consultant cannot set up and demonstrate a basic but correct org structure and basic business process within six weeks– unless you have less than optimal consultants. This is another chance to evaluate whether or not you should keep this person on your project. If you want breakthrough business results, then you need truly talented consultants. If you settle for less, then you will also settle for less than the results you really want from this huge investment.
Obviously, any SAP, ERP, or technology project involves risk. If you identify and address these risks early on in your project, you set clear expectations about the quality of the work and what the final result should be. There are things that need to happen on the company side of the equation as well, but this article addresses your investment in the system integrator.
If you make the hard decisions up front, and if you are diligent with taking steps like what these articles define, then key project expectations about success and results will be set. These approaches help you see through a lot of the hype, hoopla, and sales garbage that is so prevalent. Additionally, these approaches set expectations about the quality of resources you want on your project. You cannot anticipate every avenue some unscrupulous or desperate vendor might take, but by setting certain expectations and keeping the “traps” in place early on, you are more likely to eliminate those vendors from the process before they can do any damage. By being diligent early in the process through changing improper resources (and possibly demanding credits), you set a tone and expectation about the quality of results you expect.
Four Part Series:
Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results
