Lesson #82: Project Management & Prioritization

Startups always have a million projects on their plate, trying to change the world.  Often times these projects revolved around their technology and building out their product/website/app.  Today's lesson is about how best to prioritize, manage and develop these projects.

First for prioritization.  When I was at iExplore building out the original website, we had a list of 200 features and functionalities we wanted built into the website.  A list that long is too cumbersome to build into your beta website, which should be kept to a minimal viable product (MVP) to get it tested and into the market sooner than later.  So, we needed to pick which 10 features of the 200 we desired long term were going to be most critical to our launch.

The way we prioritized our tech list was to determine: (i) which core features were "must haves" for launching a product that consumers would be excited to use (and sufficiently differentiate ourselves from our competition); and (ii) which features will do the biggest job of moving the revenue needle or meeting our other customer acquisition goals.

So, in launching iExplore, we decided a robust one-stop adventure trip finder was the absolute key to our initial launch, and we would roll out a tour book section (for researching needs) and a travel community section (for social needs), in versions two and three of the service.  Then, within the trip finder section alone, there were a lot of features therein that we needed to choose between in prioritizing our efforts.  But, we started with ones that we though would best assist us with closing bookings (e.g., live chat functionality with expert agents, robust photo/video gallery for each trip, sophisticated data model for easy searching by destination/activity/price/difficulty/comfort).  Everything else on our list got prioritized in a similar manner, and put into a production schedule for interim future releases throughout the following year.

In terms of managing the project, it comes down to: (1) making sure the entire team is clear on what they are building (and that they had input in such vision); (2) making sure the team is entirely clear on the date of delivery; and (3) having the team work in an agile process of development.

If you told your team you were building a new car, you would be surprised how many different interpretations your team may have, in terms of what type of new car you were building.  Some may think red, others blue.  Some may think van, others SUV.  Some make think luxury car, others may think more mainstream.  So, you need to pull your team together at the time of the project launch, and through the process itself, to collaborate and collectively agree that the new car we are trying to build is a yellow luxury sedan.  Hopefully, this open communication process will eliminate any confusion amongst the group in terms what it is you are actually building.

In terms of communicating a delivery date, that is pretty self explanatory.  But, people need to be managed in bite size chucks along the way.  If you tell the team they have three months to finish the project, they may work at 35 mph for the first two months, and then realize they need to work at 90 mph for the last month to have any chance of catching up.  Which all that does it put stress on them and the rest of the team.  So, instead of saying "deliver me the full project in 100 days".  Say, "deliver me the first 10% of features within 10 days, then the next 10% within the following 10 days, and so on."  It keeps them focused with acheivable deliverables within shorter time frames and keeps the overall project heading towards its overall goal.

The last point is about having an agile style of development.  In the old days, the management team would think through the entire project, building the specs for everything, hand it over to the developers and then they would start building out the entire project.  And, to make matters worse, there was very little interaction between management and the developers doing to the work in helping to set priorities and understand the overall business objectives. 

The problem with that old "micromanaged, waterfall" style of development is: (i) the people doing the development in the trenches did not have clear insights into what the company's goals were or how their work fit into the bigger picture, where they could offer additional ideas to help; and (ii) almost always, whatever vision management had day one, is most likely going to change within the first couple months as they are getting new information to work with, so they wasted a lot of time building a full technology specifications document for a site that almost immediately becomes obsolete.

So, in today's day and age, the iterative and incremental agile development process is the way to go.  The key components of the agile manifesto are: (a) individuals and interactions, over processes and tools; (b) working software, over comprehensive documentation; (c) customer collaboration, over contract negotiation; and (d) responding to change, over following a plan. Or, said another way: (i) open communications and collaboration with the entire cross-functional team from ideation through completion; (ii) small bite-sized projects that need to get completed every two weeks; and (iii) each person on the team responsible for one specific piece of the puzzle (e.g., Joe tackling sign up form functionality, Jimmy doing user design, and Susie doing database integration).

To learn more about the agile style of development, check out this tutorial on the subject from Wikipedia.

Hopefully if you follow these suggestions, you will keep your projects on time and on budget, and built in a way of open communications and achievable goals that motivates your team. 

For future posts, please follow me at:  www.twitter.com/georgedeeb