Loading ...I know I said that building should only start once design is completed… this would be ideal, but it’s not always possible. Why not? People often wait to finalize the compensation plans before starting the planning process. Typically plans are not until a few months before the next fiscal year, so that usually leaves very little time for implementation. What more, the analyze and design phases rely on those plans to be completed.
So can we start implementing without the comp plans? It depends. More often than not, we have a very good idea of what the plans will look like, how the calculations will be performed, which bonus exist. The information that is lacking is the quota amounts, bonus amounts, or which particular bonus applies to whom. Even without this information, it is possible to start working on the analyze and design phases.
With this in mind, if we can map out all the information we know, it will be possible to take big leaps in our initial phases, and even in implementing major components of our sales performance system. Once the missing details become available, it will be time to revisit the documents to keep them up to date.
This should give more time to properly implement the system without cutting corners, and to meet the deadlines. Like I said, this is not an ideal scenario, but it is much better than waiting until 3 weeks before the required “go-live” date to start implementing.
I think one of the biggest stumbling blocks I’ve seen actually comes from the current PMI project management methodology. Under the current PMI “doctrine”, a project should do only the work required to accomplish the project’s scope, *and no more*.
The problem, of course, is that it’s almost always cheaper to paint yourself into a corner in the short-term. From a practical standpoint, too often we design and implement to the current compensation plan *exactly*, rather than designing to how the compensation plan works generally.
Quick example: I want to rank Payees assigned to a Territory within their Region. Great, so I go off and configure the system to rank occupied Territories within their respective Regions. (Let’s assume, too, that I only care about occupied Territories. In other words, I’m ranking the Payees, and not the Territories themselves).
Too bad the *generic* requirement is to rank occupied low-level Geographies within a higher-level Geography. If I design poorly, I’ll forever need to go back to IT resources to change “Region” to “District”, “Big Geography”, “Nation”, etc.
Hi Chris,
It’s true that PMI encourages to keep the project to it’s scope (and boy do we know that scope creep can be a real project killer!), but PMI also encourages to revisit the scope throughout the project lifecycle. In other words, scope can creep, as long as it creeps in a controlled way.
But I agree with you, it is important to A) know how to read between the lines when interpreting requirements to implement a flexible system that will meet today’s requirements, but also tommorow’s requirements, and B) know how to define requirements properly in the first place.
I completely agree. Point B) is especially essential, and often missed.