Frameworks

Frameworks

Projects are a funny thing.  Everyone’s been on one at some point in their lives (even if it’s as “simple” as planning a trip), which means everyone kind of knows what to expect.  This is good, because it means we all have some general idea of what the next steps are… but this is also not good because we all have our own assumptions / pre-conceived notions of what to do when.

Why This is good

All projects follow some version of ideation, planning, execution and completion.  Exactly how that’s done differs, (for example Agile iterations over that execution and tinkers with planning while Waterfall sets it in stone), but all of that happens in one form or another.  This makes it (relatively) easy(er) to translate our experience from one project to another, even if the exact topic or domain differs.

This is a good thing since we all have at least SOME shared experience.  We’ve all had that moment of terror when we forget a detail and have to scramble to fix it.  We’ve all had that moment of satisfaction when the project or milestone is done and we can check something big off the list.  This makes joining a new project a little bit easier; we’ve seen how it’s done.

Why this is really not good

This familiarity, however, has a downside.  It makes us complacent.  It allows us to “safely” assume that one project will be anything like another, or that how one project is run will be how future projects are run.  While this may lead to minor annoyances in smaller projects, it can lead to catastrophic problems for larger ones.

How to avoid the not good

There is a way to both capitalize on prior experience and avoid the pitfall of assumptions, and that solution is a framework.  Frameworks give the team a shared understanding of what is expected.  They take work to develop, teach and maintain, but the effort is worth it.

Building a framework is as simple as laying out steps to follow.  Answering questions like 'how will we prioritize new work' or 'how will we run testing meetings' will help clear up confusion and avoid problems before the occur.

Just making a framework isn't enough though.  We also need to gain buy in from the team, ensure they understand how to use it, and then actually use it.  The payoff, though, is worth the effort.