Tech Project Survival Guide

Right now I'm working out of River City Labs and meeting a lot of folks who are in start-up mode.  Full of entrepreneurial spirit, in some cases backed by other peoples cash, and all finding themselves with varying levels of skill in managing a technical project.

To try to do a an ultra-dense, nutshell presentation that compresses the top few tips I have learned about getting a tech project to success, I decided to try out PowToon.  It needs some work, but have a look and see what you think.  I may yet replace the music with a voice over.

My talking points about what I wanted to say are summarised below.  At present the video does not have voice, just the music that came with the PowToon software.

• Tech projects involve 
• project owners who have an idea they want realized
• and technical experts who think in terms of what artifacts are needed
• there is a natural tension that can result in bad outcomes
• if you are the project owner YOU must work to fix this
• YOU must make sure communication channels are working
• good tech experts have lots of work to do without doing your job for you
• As a project owner its tempting to think of your idea like a plan for a house
• it can simply be built like other houses
• you don't need to specify everything
• we'll come back when its all done
• but technical projects are not like that
• a technical project is more like a journey 
• project owners and tech experts must travel together
• your spec not a house plan, is a chart into unknown territory 
• and it will have to handle change
• When your project is on course, completed code is piling up
• maybe you have an in-progress app or a website 
• that means NOTHING without the code
• the code is what makes your screens & web pages actually work
• without it you have nothing - what if your developer leaves?
• no more changes can be made - the whole site/app will need to be rebuilt
• project owners MUST track the code that is being written for them
• NOT OPTIONAL - you MUST do this, techie or not
• successful tech projects put their code & other artifacts in source control
• if you already know source control, then good: 
• if not learn:
• what is a source control "repo"?
• how do I log in to mine and see the commits?
• who has access?
• NOT OPTIONAL - you MUST do this
• Join the crew, be part of the technical team.  
• Check your project plan - its your map of the planned project course
• But reality is not the plan.  The plan is an idea.  It may need to change.
• As a project owner you are expert in the goals of the project, and 
• your technical crew are expert in the tech needed for the implementation.  
• the cleverness/coolness of implementation comes AFTER meeting the spec
• work to get your features the best way within the technological constraints
• Don't treat them like "resources", and 
• stay on board with them.  
• Earn their respect
• just paying on time is not enough to achieve this.
• If you have your head in the project plan and don't talk with your team 
• you will blow off course and your results will show it
• Iterate with your team.  Daily.  Weekly.  Watch the artifacts pile up.
• Check your implementation against your spec.  Look for gaps.
• Keep your charts up to date, and map your current location.
• Know where you are every day.  Avoid surprises.
• If for some reason you can't be at the helm
• find a trusted project manager
• with no-one at the helm you'll go off course & the project will founder

In summary - if you are a project owner, don't just give your technical project team a brief and tell them to go for it.  Your idea is mostly in your head, and your technical team is not psychic - if you want the project to fulfil your vision you have to work with your team throughout the duration of the project.  Creating ever more detailed project spec's is one answer, but its no substitute for communicating with your team, checking in every day, and making sure you're on track.

This allows you to work with them to make the implementation fulfil your goals.  Your plan will likely need to change - maybe there are cheaper, easier ways to get something done technically that achieves the same goal business-wise.  You'll never know if you are not on-board with your team, working with them.  Course corrections can be made before you drift too far off track.

And.  Use source control.  Even if you're non-technical, learn what it is, why its used by every successful project; and how to access at least the web-console for your source control "repo".