Ensure technical feasibility within the time limit proposed for the project.
Step 1 was probably easy for you. As the business leader, you probably felt comfortable dealing with business objectives. You may be less comfortable with technology issues and, even more, with geeks. Fear not. Read on. The questions are here and the answers should be devoid of any techno-babble.
Technology is evolving with ever increasing rapidity. But not all innovations succeed, or live up to their initial expectations. While strategic business decisions often flourish on the back of advanced technology, research and development of these technologies is best left to those with resources and budgets to bring them to commercial realization.
Delivering viable business solutions should be premised on tried and true technology and processes along with sound knowledge of the business outcomes expected. Relying on bleeding edge technology is not a sound business strategy. Where has this technology worked? Do we have the same expertise to achieve a similar result?
The continued dissatisfaction rate of IT projects amongst business users is not generally due to failures of technology however. Its real source can be found in the optimism of IT personnel. From junior programmers through to CIOs, there persists an enthusiasm and can do attitude which, while admirable, is inevitably misplaced. Is this an optimistic or pessimistic plan? (But it’s not a binary question.) Most new technology requires a learning curve to achieve proficiency in its use. This includes coming to understand the undocumented features, or bugs, in new software releases. Is there sufficient formal and ad hoc education time in the plan?
Business leaders, too, are often a contributing factor in overly ambitious IT project plans. Arbitrary implementation dates frequently drive project planning. Of course, there are always valid business imperatives, sometimes even regulatory issues, which new solutions are designed to address or which constitute the very rationale for the project. Unrealistic timetables, however, are an invitation to failure. Is the end date the result of the plan, or is the plan the result of the end date?
In our experience it has been rare to find a project plan which anticipated key resource sickness, took statutory holidays (Christmas excepted) into consideration or scheduled meaningful checkpoints for project review. And then there’s Murphy’s Law. What would you accept as a reasonable allowance for the fickle finger of fate? How much slack is there in the plan?
So, a sceptical CEO should be prepared to ask the obvious questions – Is this plan technically reliable, achievable and robust? and expect three very distinct and affirmative answers. Any dissembling or hesitation must be taken as a ‘no’. Send the plan back and demand an explanation of all revisions, but please, not judgmentally.
But there’s an equally important question to ask, of both the IT team and the business team. It’s not about technology however. Are the business participants confident in their ability to provide the input to the design team, validate IT’s conclusions and adjust their business practices to the new systems – all within the allotted timeframes and while continuing to run the business? Because it’s not as if the business, too, is not changing and evolving.
Theoretically, the plan may be doable. Practically it may not. Both the geeks and the business users must be comfortable answering these questions in the affirmative. But you are the only one who can ask them – while encouraging honest answers. Your job may depend on it!