One of the advantages of coming together as a community is to learn from what others have experienced. Within Information Systems & Technology (IST), we recently completed an analysis of our 2017 project lessons learned. These lessons are a combination of opportunities for improvement and things that went well for projects.
- 25 percent of our lessons learned reported pertained to communications management
- 20 percent of lessons learned pertained to procurement management
- 17 percent of our lessons learned pertained to scope management
Top 10 lessons
Here are IST’s top 10 lessons across closed projects in 2017 (in order, from highest number of repeats):
- Manage vendor throughout the project
- Assess potential impacts and dependencies as early as possible
- Communicate across all stakeholders early and often according to interest and impact *
- Understand requirements and objectives to appropriately define scope *
- Manage and collaborate with stakeholders according to their interest and impact
- Gain support from stakeholders up front
- Ensure vendor quality and values align with University expectations
- Ensure the right resources are available and their commitment understood
- Communicate with appropriate methods
- Reiterate project goals often
Of these lessons, the two marked with an ‘*’ are repeated from the previous few years, continuing to be issues for many of our projects. There are many reasons why these are continuing issues, some of which may include:
- Communicating with some stakeholder groups is much more difficult than others (e.g. students and faculty who don’t typically read an email or other common methods used)
- Finding the balance between too much communication and not enough communication for stakeholder groups
- Not doing the appropriate stakeholder analysis to understand the interest and impact of various stakeholder groups
- Projects don’t always have access to resources with communications expertise
- Objectives and scope can be somewhat “fuzzy” when first defined for the project, making it difficult to know what success should look like
- Identifying the appropriate people who can provide requirements can sometimes be difficult on campus
- At times, we don’t spend enough time on gathering requirements because this process can be difficult and time consuming
- Projects don’t always have access to resources who are skilled at helping stakeholders define their requirements (e.g. helping them distinguish between what they need vs want, or even pull the requirement from every day processes and put it into words)
Let's hear from you
- Do these lessons sound familiar to you with your projects?
- Do you have additional key lessons that aren’t included above that you can share with the community?
- What ideas can we share on how to address some of these issues that continue to arise for our projects?