I’m rolling off the first big project of my tenure here at The Academy.  It was a success, but it didn’t come easy.  There were some salient lessons learned that I think are worth sharing.

Have extremely high standards, but be okay with the fact that they won’t be met entirely.

When you start with, work toward, and fight for ideal processes and methods, you at least have a sound foundation from which the project evolves.  Not everything you want will be possible, due to any number of limitations, but if you get at least some of what you’re striving for, you have a good deliverable at the core.  Conversely, if you go in with complacency, low expectations, and no sense of innovation, you won’t find yourself driving for excellence – just completion.

It won’t be perfect – and that is perfectly acceptable.  What is not acceptable is starting with the premise that you won’t strive for perfection – fortunately, that’s not how I roll.

I didn’t get everything that I wanted, but I did get some things, and those are successes not to be overshadowed by not getting everything.

Carefully vet your third party’s capabilities before committing them to your solution.

This feels so common sense, but it’s a trap I fell into.  Be particularly cautious when innovating with a solution or code that is out of your direct control.  Some tools are simple to use, and were never intended to become more complex. Just because you believe what you you’re trying to do is a logical extension of what you’ve already done with a given technology, that doesn’t mean it’s going to be possible.  Give developers ample room to explore new functionality and methods up front, and build in more testing time than you think you’ll need.

Even small projects need requirements.

Try to see this coming.  If you’ve been there done that, the documentation is probably overkill if you’ve never needed it before.  But if you’re pushing some boundaries, take the time to get line-by-line requirements and map those to dependencies.  This way, you can evaluate each requirement/dependency relationship and better dispel false assumptions before you get deep into the project, where they can let you down in a big way.  Sometimes it’s not just the big, formal projects that require traditional structure.

-cp