What Makes an IT Project Successful? Nonprofit Edition, Part Two

What makes an IT project successful?

My last post covered a few common denominators I see in successful IT projects at nonprofit organizations: executive vision and involvement, defining requirements, and proactive risk identification and management, all of which provide a solid foundation for executing a project.

This post will cover key considerations after you’ve thoroughly defined the project, secured sponsorship, and documented risks: getting the right people and team structure in place, managing changes to the project, and preparing the user population for a successful go-live.

Resources

The project team and structure will largely be dictated by the scope of a project, but in general I’d suggest thinking in terms of a few key groups (I’ll dedicate a larger post to this in the future):

Steering Committee:  Every project needs an executive sponsor, a single individual accountable for its success and able to make key decisions that can’t be resolved within the project team itself (more on the concept of Executive Sponsorship here). In addition to a sponsor, I’d suggest creating a committee of key leaders within the organization to act as a steering committee for the initiative, ensure clear communication at the executive level, and foster organization-wide focus on project objectives (more on articulating the value of an IT project here).

Project Manager:  The project manager carries out the day-to-day management of the project and acts as a single point of contact for all project issues. Make sure your project manager has capacity to focus on the project and actively manage the team, as well as project budget, risks, issues, status reporting, and any third-parties that may be involved. Too often this function is given to a staff member who already has a full-time job. While this may work for smaller projects, larger implementations cannot be managed in someone’s “spare time.”  At the same time, be careful about fragmenting the project management function across multiple individuals (unfortunately sometimes this is unavoidable for large projects), as this requires an additional level of coordination among resources, increases project overhead, and creates room for things “falling through the cracks” between project managers.

Core Team:  These team members represent the backbone of your project, carrying out the bulk of the detailed activities, coordination, and decision-making. Within the Core Team I’d suggest thinking about the different functional areas (e.g. gift processing, major giving, events) and assigning a single lead for each area responsible for coordinating all aspects of the project that touch that area, as well as coordinating with Subject Matter Experts and End Users who work in that area.

The Core Team escalates issues up through the Project Manager, as well as translates the project vision and strategy down to the individual team members. Also, think about key roles within the project – for instance, technical architect, trainer or report developer. Identify the individuals filling these roles early, recruit individuals who have worked on similar projects wherever possible, and ensure those individuals are involved from the beginning of the project, even if their utilization on the project is intermittent. Otherwise, you risk the all-too-common scenario of getting to a project milestone and realizing that the next phase isn’t properly staffed or a key team member is over-scheduled.

End Users:  Involvement of end users in a project seems to be controversial for some (admittedly, the adage about “too many cooks in the kitchen” comes to mind). However, the success of an IT implementation depends on users actually using the system, so I’d recommend finding meaningful ways to involve end-users, such as  validating requirements, ensuring alignment with business practices, and testing the system. This is particularly important for federated organizations with chapters or regional offices, where the needs of users in the field (commonly volunteer or part-time staff) can vary dramatically from those working in headquarters on a national level. At a minimum, ensure communication planning addresses key stakeholder groups so there are minimal surprises at go-live.

Change Team:  These are your evangelists and communication leads for the project, responsible for monitoring and managing the project’s impact on the people within the organization, with an eye toward ensuring user adoption (more on Change Management and Adoption Readiness below). I typically think of the Change Team as parallel to the functional project structure to provide a somewhat independent channel for communications – both up and down the hierarchy of the organization – and to maintain focus on the Change Management effort, as project team members are often focused exclusively on the detailed work of getting the system up and running.

Scope Creep

Scope Creep describes the phenomenon by which project requirements increase during the execution of a project. This is completely natural – project stakeholders naturally want to see their needs (and sometimes personal agendas) are taken into account, although often those needs fall outside of the domain of the project, its technical feasibility, or its budget.  A few common examples:  “We’re converting this database, why not this one as well?”  “You’ll need to find a way to get this spreadsheet into the system.”  “We need to customize the system to support (insert unique business process, interfacing with a third party system, specific workflow, a separate business unit, etc.).”

My last post covered the importance (and challenge) of requirement gathering and definition to provide a detailed framework and target for project activities. Once requirements are in place and agreed upon, the project needs to be managed carefully against requirements. Sure, requirements will change (some would say this is inevitable, but reasonable people can disagree), but changes to project scope should be deliberate and managed through a change control process that takes into account impacts to timeline, resource commitments, risk, budget, and other considerations.  Keep in mind that project complexity increases exponentially with increases in requirements, and that larger projects are more difficult and time-consuming to manage than smaller ones.

Change Management and User Adoption

While I’ve listed Change Management as the last item in this post, the reality is that a large-scale change effort starts during project initiation, when project scope and objectives are defined.  Anyone who has worked through a long project only to see a system fail because of low user adoption will likely understand – you can’t back into user adoption at the end of the project, the transition between systems and processes and impact on people needs to be managed over the course of the project.

In a nutshell, user adoption is driven by a few key factors (see this post for more on user adoption):

• Do users perceive the system as valuable?  This entails understanding what users desire from a system and their perceptions on how a new system will impact their jobs, as well as communicating to users about how the system will deliver value to them in a personal and specific way, not just the value to the organization as a whole.  Keep in mind that effective communication is an ongoing and evolving process coordinated through multiple channels, not a one-time event.
• Do users perceive the system as easy to use?  Where appropriate, consider integrating training and user education into your project communications beyond standard “end-user training.”  Examples might be demonstrating key features at an internal event, including a preliminary training for members of your core team and other stakeholders, offering role-based on-demand training during the project, and scheduling remedial training and personalized user assistance (often referred to as “hand holding”) for the weeks following launch.
• Do a users peers use the system?  Think about the Change Team mentioned in the Resources section above.  This group should consist of influencers throughout the user population to acclimate users to the new system, as well as informally collect feedback out the system and the project.  Communications on an ongoing basis will reduce misunderstandings and allow issues to be addressed earlier in cycle.

Take these into account during project definition and planning to “start with the end in mind” and maintain focus on the desired outcome.

These are of course just a handful of considerations when planning a project.  I’d love to hear the experience of your nonprofit in the comments.