Lately, I’ve come across several proposed new systems, processes, and forms — all developed to address an assumed real, but unstated need. In most cases, I could see a useful purpose for the new system/process/form, but it usually wasn’t provided to me explicitly. I didn’t know if my interpretation of what this new proposal was all about was shared by those directing it so I often feared I would be wasting my time by doing something that wasn’t what was actually wanted.
Developing a common framework and tools for management tasks makes sense, but there must be a system behind them, else you just end up creating a bureaucracy instead of an effective, efficient system. I see several things to address before implementing a new system, process, or form:
- What is the purpose/goal? What problem are you trying to solve?
- Who is your audience?
- What are the requirements needed to fulfill your objectives within your target audience?
- What are the implementation costs?
- What are the costs of non-implementation?
- Given all the above, is implementation the right approach?
There’s nothing terribly new here, but the items above make a good checklist to go through before starting a new formal process. If you don’t address the first three points, you may end up spending a lot of time doing something which propels you no further down the road. In addition, if you don’t evaluate the costs of what you’re proposing against the current incurred costs in light of your available resources, you risk spending too much time on something that is ultimately not going to improve your situation enough to be worth it.
Large projects need a fairly broad framework in which to operate. They also, typically, staff a project office sufficiently to help produce and support this framework. While smaller projects can also benefit from this same framework, typically the cost of doing so is prohibitively high. So, smaller projects must think carefully about what it can do, what it can’t afford not to do, and ignore the things it can afford to not do. Going through a similar checklist as above ought to help decide into which category a proposed new system belongs. (Actually, I’m sure this same approach works for large projects as well — we are all resource-starved these days.)
Speaking of checklists, Scot found the book “The Checklist Manifesto” by Atul Gawande a very good read and a great strategy for helping to ensure routine tasks are done correctly every time. Packing for trips, as an example, got immensely easier once checklists got involved.