I have been working on a project that would make the management of summer conferences on campus easier and more efficient than the “by hand” method that is used now. Essentially, the system has been a series of Excel spreadsheets, emailed back and forth and stored on a shared network folder. Lots of revisions, not very effective, not to mention that if someone has the document open and another player needs to make a change, there is a lockout. Last week I convened a meeting between the departments that run the conferences: Housing, Scheduling, Dining, and the departments that run our orientation: Student Life, Registrar, Academic Advising. The reason these two groups where brought together is the thought that our orientation is essentially another conference with some specialized needs, mainly the academic information. This brings me to the title: Mission Creep
Mission creep is the expansion of a project or mission beyond its original goals, often after initial successes.
I believe I have some methods to reduce Mission Creep:
- Get your mission defined by the highest person up the food chain.
Having your objectives defined from high up the food chain give you grounds to tell people exactly what the mission is. People like to think that the project is working solely around them, so having the projected outcome set by someone much higher can limit that though process. And don’t be afraid to go back to the mission definer if you start to feel some creep.
- Have a documented process.
This was my first mistake. Not having a document process will allow people to take over how the project is managed. They will jump ahead in your process, most likely creating more work. Have a written process that is given to each of the members of your team and anyone else who is related to the project. This lets them know how you work.
- Be ruthless with meeting invitation and the distribution of meeting notes.
Everyone thinks that their opinion is valuable to your discussion. I think it is a fundamental fact of human existence. The problem is that they can add more work at an earlier stage than is necessary. Limit who is invited and make it known that your meeting notes are for participants only. If someone up the food chain, or someone laterally involved wants in, they can be brought up to speed later.
- Don’t be afraid to tell people that they are not currently needed in the process.
This is a great follow on point. Everyone’s opinion is valid, but not always relevant. If someone is only going to slow down your meetings, or disrupt your process, minimizing their involvement as much as possible is critical to your mission’s success.
- Understand that people can be “read in” if necessary.
I have picked up the term “read in” or “reading in” from television shows, generally where some agency is dealing with classified information. Essentially is is when someone with the knowledge catches someone outside the project up. This may be a one-on-one, quick review of what has been done so far. It may be simply sending them your meeting notes (be careful about this).
Right now I find myself mired down by not following my own list of rules, hopefully the late application of these ideas can correct the course for the summer conference software project.
