Characteristics of a good project sponsor

Depending on the project management methodology has been adopted for a project you may have an Executive (Prince2), a Product Owner (SCRUM), a Project Sponsor (various) or similar person.  They are the one who has the ultimate decision making power on a project for features that are in or out and what the implementation of those features looks like.

Ideally this should be a single person, if you have a committee making these decisions, you have a much more difficult road to travel.

This person is a key ingredient to the success or failure of a software project.  The last thing anyone on a software project wants is for it to be cancelled, stalled, or delivered as a high performance well-engineered solution that no one uses.  If you build a good working relationship with your sponsor and you are able to work collaboratively together then they will be a great asset and the project will be an enjoyable experience for you both.  If the relationship becomes fractious or adversarial, then expect to see your job satisfaction head down hill.

I know, I know, you didn't necessarily get into IT because you wanted to spend a lot of time dealing with people.  If you did, you would have worked in sales, or marketing, or HR right?  Let's face a truth that is awkward for some IT professionals to face; its all about people.  Whether it is your boss, or your team, or a cross-disciplinary team, you will have to deal with people.  If those relationships are smooth then those 40 hours or so you spend at the office are a more pleasant experience.

These things aside, an effective project sponsor will possess the following characteristics:
  • The ability to make (and stick to) decisions.
  • The ability to prioritise feature requests from competing voices.
  • Strong understanding of the domain (area of business) and the concerns of the end users of the software product.
  • Availability and ease of access for development team representatives.
  • At least a cursory understanding of the technology involved in the software project
  • A degree of 'gravitas' / authority / respect within the client organisation  They need to have the authority to make decisions and the gravitas to ensure that they are followed up.  Alongside this is a degree of budgetary and resource control.  If purchasing a third party software library will reduce the timeline significantly, could the sponsor secure that funding?
  • A listening and compassionate ear to concerns raised by the development team.
  • The ability to focus on the business case and make 'hard-nosed' financially imperative decisions.
  • A degree of flexibility, and openness to negotiation of timelines and feature sets.  An inflexible person will ultimately be faced with disappointment.
One oft-forgotten measure of the success or failure of a software project is the number of the development team who leave their employer in the weeks following the release or delivery a product.  This 'voting with the feet' expresses a serious lack of confidence in the persons responsible for leading the project.

Comments