"Information technology is increasingly important to corporate performance", states McKinsey's paper on IT as revenue generator. Nearly half of respondents to the consultancy's most recent Global Survey (the results of which formed the basis for the paper) believe that IT-enabled business innovations will account for at least half of their future corporate earnings growth, up from only 18% who said so in 2010.
Corporations are addressing these needs by growing internal IT capabilities which can, in turn, oversee and manage growing numbers of IT consultants and contractors needed to undertake these projects.
But small businesses are facing the same pressures to build IT infrastructure but often without any internal expertise to oversee the outsourcing process. So how do such businesses navigate the information asymmetry to ensure projects are delivered on budget, on time and achieve the necessary business objectives?
Here at Groom Kennedy we have outlined the following five governance principles for equipping small businesses with the knowledge to oversee IT projects:
1) Understand and articulate why you are embarking on the project in the first place
Question #1 in the Wall Street Journal's article 'Four Questions Every CEO should ask about IT' asks:
"Are we using technology to transform our business, or are we just adding bells and whistles to existing processes?"
IT change is best managed proactively: a clear business need is recognized and a thorough search is then carried out to determine the best solution to fill that need. However, there are many examples in the marketplace of small businesses choosing projects reactively: "because our competitors are doing it" or, worse still, because a firm came and pitched the idea and it sounded worthwhile.
Incremental change is often positive and necessary but, as the authors of the above article point out, "[w]hat is far more lasting—and much more difficult—is for companies to rethink how they deliver core customer services."
Understanding the strategy behind change will allow you to better articulate your needs to IT partners and recognize when the project is changing direction or suffering from scope creep (a key reason behind delayed or over budget projects).
2) Ensure (and maintain) clearly defined 'requirements'
Once you have articulated your purpose, the next step is to articulate your 'requirements': a more tactical summary of the specific business functions this project will carry out.
A task completed by someone else will only be as good as the clarity of the instructions you provide. Don't expect that IT projects are any different and that they will be completed end-to-end by someone else. You and your operations team must devote significant time up front articulating your requirements. Like any set of instructions, incompleteness, ambiguity and any changes after finalization have the potential to cause significant issues downstream.
In his article for the Australian publication CIO titled 'Why IT projects really fail', Hemant Kogekar cites "fuzzy goals" as the first reason for IT projects failing. Importantly, he provides that the key here is not just making the requirements clear enough from the outset but also ensuring this clarity is maintained once multiple stakeholders become involved: "[o]ne executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced, adding their ideas of what would be best."
3) Require best practice project management communication from the outset
In a nutshell, this means:
· A list of clearly articulated and mutually agreed end-to-end project milestones (with key dependencies and due dates)
· A list of project risks with a simple rating for both likelihood and severity and a mitigation plan
· A list of project issues (i.e. risks which have eventuated) with a resolution plan
· A regular meeting cadence for calling status on the above
4) Consider hiring an independent QA
Given the relative cost of larger IT projects, it may pay to hire an outside expert who is independent from the project execution team to provide impartial oversight and Quality Assurance (QA). This only needs to be a light touch role (i.e. attending key meetings and reviewing materials) and as such may only constitute a relatively low additional cost to the project.
5) Brush up on your knowledge of basic IT frameworks and terminology
Enterprise software developers strive for quality through predictability. As such, the industry uses fairly standardized processes and terminology. The software development process or lifecycle (SDLC) works through a logical set of steps to take a project from concept to completion:
1. Planning (including developing requirements)
2. Implementation, testing and documenting
3. Deployment and maintenance
There are many resources out there that can help you develop a base level of understanding in a relatively short period of time, such as Peter Weill's book IT Savvy: What Top Executives Must Know to Go from Pain to Gain (N.B. Weill is also the co-author of the abovementioned Wall Street Journal article). Those wanting to invest more time in developing a broader understanding could undertake a free MOOC course from one of the world's top universities, such as Harvardx's Introduction to Computer Science.