I was having a conversation with someone recently about what makes a good project sponsor because they were raving about the one they currently had for a couple of projects they managed. I found the discussion interesting because I’ve come across the best and worst examples of project sponsors in my 3 years at AtTask. After a rather lengthy conversation we concluded that there were three attributes that make a good project sponsor; influence, power, and authority. If a sponsor has one of those it was ok, if they have two its good, but if they have all three then you have a great project sponsor!

Influence occurs when a person or group affects what another person or group does or thinks. For the purpose of this post we’ll assume we’re only talking about people with a positive influence. When we talk about influencers on a project team it could be anyone from the guy with great ideas, to your project sponsor or even a stakeholder. Influence is often developed over time but is generally controlled as a substance of good will or a well held position or belief. Think about the people on your project team or in your office. Those who often have the most influence are the people who you get on well with or have a close relationship with. You’re more likely to value their idea’s or direction because you trust who they are and what their motives are. There are also those people who you may not have close relationships with but are able to explain an idea or instruction in such detail and order that it would seem absurd not to support or carry out the request.

Think now to your Project Sponsor, does any of the above apply to him or her? If the answer is ‘no’, then would someone who had such influence be more beneficial to you as a Sponsor? Would your Sponsor be more effective in the project role if they could influence you and others on the team?

Power is the potential or capacity of a person or group to influence other people or groups. There is a very fine line between power and authority but the key to power is ‘potential’ rather than a ‘right’. To make things even more confusing power is also closely linked to influence in that if you don’t have the ability to influence others then your power is diminished. In a project team the Project Manager has the power (or discretion) to make decisions about how the project is to be run, managed and delivered but authority is needed to uphold those decisions and to enforce them.

Your Project Sponsor probably has power to do a lot of things within the organisation because of their position or job title, but so do the project team members. Project team members have power when they are required to perform a role or task that only they can do because of their specialist skill or knowledge. No authority has been given to them, and they may not have much influence over others, but because of the power that comes from their employment as an individual they can control the outcome of a situation. Take for example peer-to-peer performance reviews. If a the Project Sponsor asks you how Mr Project Manager is doing in their role, you have the power to give either a favourable or unfavourable review. Whether or not your review holds much credence will depend on your influence.

Authority is the power formally given to an individual or group to make and enforce a decision. This seems to be the most obvious attribute of good Project Sponsor. Authority can occur at many levels. In a previous job I used to be a system administrator for a project management system. My boss at the time (an ex-Army officer) would say to me “Russ, if any of the managers come to you saying they have to have a higher access level, I want you to say to them ‘Don’t confuse your rank with my authority!’.” Even though those managers were more senior than I was, I had the authority from my manager to control others access. I would hope that there are very few of you who know a Project Sponsor that does not have the authority to make decisions or to support those decisions which you have made. Unfortunately, because of the original conversation that sparked this blog post, I know there are.

As an evaluation of the roles on your project team try placing a dot into one of the circles in the diagram that best identifies their mix of influence, power and authority. Hopefully the Project Sponsor should be smack dab in the middle!

I found myself in an interesting situation a few weeks ago whilst working on an implementation with a new customer. We’d spent the first part of the week gathering requirements from each of the stakeholders and had begun to do the configuration of the system. The project manager (who would also be the system administrator), kept excusing themselves to go to meetings and take phone calls. This in itself isn’t all that unusual, and I appreciate everyone is busy, but it can often end up being to the detriment of the ongoing usage, adoption and management of the software.

The project manager kept telling me “I have to take this call its urgent”. It made me remember something I’d once read about confusing the difference between ‘urgent’ and ‘important’. In a project environment, confusing the two can impact the results you deliver and the timeliness of when you delver them. As in life if we get these wrong we can end up under-delivering or find ourselves out of time (late!)

When something is urgent it means that it has to be done right now. Urgent things may not necessarily be important though. Take my project manager who kept taking calls because they were ‘urgent’. It was urgent because the phone was ringing at that very moment and they decided to answer it. Whether or not what was happening on the other end of that call was also important, I don’t know. If you are in a project meeting to determine the next steps of a project and how to resolve key issues and your phone goes off, do you answer it? When you ignore the phone but 2 minutes later the same person calls again, you feel an increased urgency to answer because you assume it must be important. You dash out of the meeting to answer the call and its your colleague asking if you want to go with them for lunch!

When something is important it impacts results, performance or actions. Importance can often be an individual and personal thing as well. What is important to one person may not be important to another. As a project manager it may be important to you that each of your project team gets to have 1:1 contact time with you regularly. Its not urgent because you can have this contact time at any point in the week, but its important so that they feel motivated, part of the team, and stay on the right track with their deliverables. With my project manager mentioned above, when they came back into the room having taken a call they had missed something that had been said or something we had configured in the system. Those things were important. They found themselves often asking “when did we decide that?” or “why have you set it up like that?”. We’d then spend time repeating what had already been discussed whilst they were out of the room.

The diargram you see here illustrates how some things are important, others are urgent, sometimes they’re neither but often could be both. Prioritising the right kind of activities at the right time will have a huge effect on our productivity and ability to deliver. I would imagine we all too often spend too much time in the lower two quadrant’s and not enough time in the upper two quadrants. As an interesting evaluation of your productivity, write down all of the things that you did yesterday and see if you can place them in one of those 4 quadrants. Does the number of things you did in each quadrant give you an indication of your priorities of urgent vs important?

As I’ve mentioned a couple of times in previous blog posts, I love Agile project management. I think its a fantastic approach. Someone recently asked me if Agile could be used in all types of projects that they were running; marketing, sales, services. Now I know that it can be used and some people do use agile methodologies elsewhere, but my response is, and maybe somewhat controversially, "no!". In my opinion Agile works best, and should remain, within development/programming projects where it first originated.

Agile software development is iterative. Its based on the principles of releasing usable end products in smaller chunks and releasing often. In theory Agile is about sustaining a pace of delivering which is constant and indefinite. Working software is the primary measure of progress. Now based on that brief definition of Agile, do you think that applies to the [non-software development] project that you are working on right now?

With that said, I do believe that there are many principles within Agile project management that ‘traditional’ waterfall project managers can learn from. In the 2011 Scrum Guide Ken Schwaber and Jeff Sutherland describe what they call the ‘Three Pillars’ – Transparency, Inspection and Adaptation.

Transparency - "Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen." 

Who are ‘those responsible’ and the ‘observers’ in a waterfall project? The sponsor, the project manager, the project team, and the customer. Its important to ensure that there is a methodology by which everyone will work, understand and adhere to. Agile has a relatively straight forward standard for communication, structure and deliverables but this kind of transparency should also be made clear at the beginning of waterfall projects. If not included in a project brief, communications plan, or kick off meeting agenda, it should at least be identified in the company’s project management methodology. It is also important to clearly identify what is meant by ‘done’ (a subject I’ve discussed in a previous post) so that ‘those responsible’ and ‘observers’ know when they are finished.

Inspection - "Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skill inspectors at the point of work"

Inspection is epitomised by the daily stand up meeting and, after the project is complete, a sprint retrospective. The daily meetings allow users to consult and discuss problems, barriers, plans and successes, to give an accounting of what they have done. For some hardcore scrum teams there may even be penalties imposed for not turning up to meetings! Most of the inspection I see in projects comes in the form of a periodic status meeting and a weekly status report. But with some lack of formalisation in these arrangements inspection events often fall victim to ‘prioritising’ other things. If project managers, or sponsors, could ensure that there were more frequent, possibly shorter, face-to-face inspection points I would suggest that it would be easier to ‘detect undesirable variances’ in scope, cost and quality.

Adaptation - "If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimise further deviation."

Agility. That’s what its all about. How quickly can you manage deviances outside of tolerance and then how quickly can the impact of that deviance be mitigated, managed or resolved. To quickly adapt to such change you have to have already defined what your agreed tolerances are and how they will be managed. A change management plan will assist in the process and is essential to minimise, or at least manage, scope creep. In Agile, there’s nothing wrong with deviation or adaptation but there is a clear understanding that with a finite amount of time available there is a decision to be made on the opportunity cost of doing X over Y.

Agile is quite a disciplined approach which probably accounts for the success it has had in software development. That same discipline required has also been the reason why so many have failed to embed Agile and have returned to waterfall.

If you’re trying to run [a non software development] project using Agile or Scrum, I would be interested to hear how you are getting on. If you’re not running a project using Agile though, do be open minded, and see if you can adopt Agile principles in your future projects. For further suggestions refer to the Agile Manifesto