What makes an IT project successful?
I get lots of different answers to this question – theoretically, the most important question to ask when embarking on any type of initiative – and I find Executive Directors and CIOs have different perspectives from end-users and technologists.
Sure, we all want on-time, on-budget delivery, that is self-evident. But as many of us have found out the hard way, on-time and on-budget projects do not necessarily mean a new system will realize proposed goals and yield expected value…or that users will even adopt the system as desired.
While clearly there is no secret formula for success in complex projects, here are some considerations that come up regularly in the nonprofit space, where resources are (understandably) spread thin and executive focus often tends toward Mission delivery rather than operations.
Executive Vision and Involvement
Executive involvement is a primary variable in predicting the success of an IT project. Having a leadership team aligned across an organization articulating the purpose, value, and rationale for a project goes a long way towards getting stakeholders and end-users pulling the proverbial rope in the same direction. Without a leader and ultimate decision-maker, it is easy for projects to bog down in the organizational resistance that accompanies any large change, or for team members to get distracted by other initiatives and priorities. Or, projects halt altogether when parties disagree and there is no way to make a definitive decision on a key issue.
Ask yourself: Is there an executive (or a team of executives) personally invested in the success of the project? Has this team clearly defined and agreed to desired project outcomes? Is there an ongoing plan for communicating that vision down through the ranks in a consistent, open, and ongoing manner? If not, considering pausing to get a governance team in place before going too much further.
Requirement gathering can be labor-intensive and challenging. Interviewing team members, documenting requirements, prioritizing what is “mission critical” versus “nice to have,” getting agreement across stakeholders…it can feel like a never-ending cycle. As a result, requirement gathering has fallen out of fashion with many organizations in the past few years.
That said, requirements remain the roadmap and measuring stick for software projects – does the system do what you need it to do? In combination with a clear business case, a well-defined set of requirements simplifies design and testing, two areas where projects tend to go sideways, and provides a means to clearly define the end of a project and the start of ongoing operations (anyone who has been stuck on a permanent project team likely knows what I am referring to).
I’d also suggest that going through the exercise of defining requirements is fruitful in and of itself, as it forces conversations across siloes within the organization, and often identifies larger issues, as spreadsheets, “shadow systems” and various skunkworks come out of the woodwork.
Ensure that requirements for the project are clearly defined and agreed upon among stakeholders (or at least among decision-makers, in the case where parties disagree), and that you have a way to track, measure, and manage changes in requirements as appropriate during the project.
Finally, gut-check your requirements – are they realistic? Can all requirements be met through a single project? Or would a “phase 2” be more appropriate for some items? Keep in mind that smaller, more clearly defined projects have a higher success rates than larger ones.
Risk Identification and Management
Every project has risk. Resources leave the organization (for better or worse, I find this happens frequently within many nonprofits). Leadership changes. Budgets get cut. There are many factors out of your control. However, many risks to projects can be mitigated or even eliminated with some forethought and ongoing management. for instance, do you have the resources you need to deliver the project (resource risk). Are project goals clearly understood and requirements clearly defined (scope risk). Do you have a realistic project plan and timeline (time risk).
Mitigating risk is a combination of science and art, and always a balancing process. To use an example from above, having too many requirements is as much of a risk as too few requirements. Too many project team members adds unnecessary complexity and can increase the costs and timeline of delivery.