Know Your Role and Stick to it…

By Steve Quarles on September 23, 2014 in Software Development

 

I’m very anxious to continue to follow a Study being conducted by San Francisco State University.  They are conducting a study on what makes a successful software development effort.  The premise of the study builds on my fundamental belief that technology projects fail because of people and more specifically teams.  I personally believe there are 4 fundamental roles that every software development team needs to be successful.  And one additional role that everyone forgets about…

The Visionary – On every software development project, there needs to be a visionary.  The vision for the product needs to be clear and concise.  In the Scrum world its the Product Manager.  Ultimately, they are providing direction for the product.  They have a clear understanding of the problem and how the software will help solve that problem.  The best thing the Visionary can do is to stay focused on progress and table the new ideas for “next phase”.

The Sponsor – You need to have someone to fund the project.  Sometimes it can be the visionary but usually its just the guy that cuts the checks.  That person needs to be on the same page as the visionary and the manager.  Any disconnects between the scope and budget need to be resolved by the sponsor.   I have seen the confidence of the Sponsor rattled by the slightest deviation in plan.  The best thing the visionary and the manager can do is to lay out a scope, schedule and budget and then do everything in their power to stick to that.  Budgets for “Phase II” always come through when “Phase I” gets delivered.

The Manager – This is pretty straightforward but all too often the manager and the visionary are the same person.  This can be a recipe for disaster.  The manager needs to think delivery first and foremost.  They need to be able to say no to the visionary.  They also need to clearly articulate the scope, schedule and budget to the visionary and the sponsor.  All that is just hot air though if the Architect and the Producer(s) aren’t bought in.  The manager needs to get buy in from the Architect and the Producer(s) and then they need to do everything in their power to help them.  The manager needs to be the advocate of the Architect and the Producer(s) and they need to be consistent.  When the visionary says, “Wouldn’t it be great, if we had this?” the Manager needs to think schedule and budget first.

The Architect – I had a client tell me that every developer should be an architect.  I fundamentally disagree with that.  There needs to be one person who has a complete technical view of the solution.  Not every developer needs to decide when to create a web service or when to use client side vs server side logic.  The architect needs to drive this and only with that complete technical vision in mind can an architect help a manager deliver on scope, on schedule and on budget.  I’ve seen too many developers “invent’ or “create” or “design” something that is elegantly perfect… but takes twice as long to build.  I’ve also seen developers “refactor” or “clean up” code when they should be developing their assigned components.

The Producer(s) – Let’s face it, someone needs to shut up and crank out the code.  All this talk about scope, schedule and budget means nothing if the producers don’t produce.  Sometimes producers overstate their skills or abilities.  That is why it is absolutely critical for the Architect and the Manager to lay out the detailed work plan.  Most systems have something simple that the architect can test a producer on.  Start with something like inserting a something in the database, or authenticating a user and review it at the end of the day.  I guarantee you will be pleasantly surprised, sufficiently satisfied, or concerned.  If you’re concerned you need to coach.  Perhaps you need to coach daily and review code daily.  Too many architects are producers themselves.  They produce great code and they expect everyone else to do the same.  That is not the case at all but I have seen the most concerning developers turn into producers under the watchful eye of architects that coach them to produce.

And last but not least…

The Provider(s) – (Software, Hardware, Expertise, and Resources) This can be any other outside provider that is critical to your success.  The provider of hardware is a crucial role that can’t be overlooked.  Do you have the right provider and do they know what they are doing?  The provider of software is another key role.  I see so many companies that are leveraging open source software which is great.  But time and time again, I see problems that arise and no one is there to solve them.  Your software service provider may be the software company that licensed you the product or it might be the open source community that built the product.  If you go with the latter make sure you are actively engaged in the community and helping to build the open source project, its unlikely you’ll get very much support if you are not seen as a contributor.  The provider of consulting may be a crucial role if you lack the experience or expertise to deliver.  Don’t be overly reliant on consulting if the product is critical to your business.  You’ll also need a provider of resources.  You need someone you can trust to build your team.  And most importantly you need to understand that talent doesn’t grow on trees.  Put a time frame on team building and go with the best possible options.  Don’t keep spinning your wheels looking for the perfect fit.

Before you start your next software  project, check your team for all these roles.  If you can’t identify all of the above, don’t start.  Get your ducks in a row first.  It will save you time and money!