5

A couple of related issues:

  • My sponsor is visionary but fails to communicate the vision clearly enough to allow implementation. This leads to a lot of unnecessary rework.
  • My sponsor communicates with team leaders directly without keeping me (or other project team members) in the loop. This keeps me from managing change in a controlled manner, it is hard just to keep pace.
  • My sponsor is a VP who honestly believes that some aspects of a successful project (e.g. having a continually justified business case) is his business and nobody else's.
  • My sponsor is of the (all too common) type that wants work to start on a solution before an adequate plan (or even definition of what the solution will look like) is in place.

Needless to say we wind up with significant issues on projects with this sponsor, mainly a lack of defined plans, scope creep and changing requirements. I honestly don't think this sponsor understands or appreciates the value that a PM has, but beyond the long-term job of educating him about this are there any ways to mitigate the problems these characteristics cause in the shorter term?

5

One tool I'm using in different contexts is accounting the work splitting it among value-adding and waste (or non-value-adding; you may prefer to use this name as it doesn't sound so harsh). Definition of waste differ among teams but definitely all the rework is non-value-adding. If you say "a lot of unnecessary work" I ask: how much exactly? If can provide the data it is a good starting point for a discussion with your stakeholder. It is much harder to discuss with the facts than it is with opinions.

I would back it up with all the situations that you can address to any specific issue you mention:

  • You weren't updated and as a result the team built feature X which was useless.
  • You started work without planning and you ended up with e.g. architecture that needed rework
  • etc.

Having value / waste data gathered you should also be able to show how much such "practices" cost the organization. At the same time, fixing some of them, like keeping people in the loop, costs close to nothing.

Another strategy to deal with such situation may be following "it's better to ask for forgiveness than from permission" attitude. Especially when you think about things that you do within the team, like planning. If you can take the pressure of starting instantaneously and do the thing you believe is right (planning) just do it. You take risks, but then it is really rare that people are blamed for doing good work.

And finally, it is possible that no matter what you do VP doesn't change. Than it's your call: either you accept the fact or you leave the organization. If you choose to stay there of course is a lot of damage reduction to be done, e.g. isolating the team from random decisions as much as you can or trying to introduce work organization that absorbs such things (small batches of work, tight feedback loops).

3

A few things I have tried, with varying degrees of success (but all certainly better than nothing:

  1. Identify the risks and state them as known constraints. When told to "go", accept it, but make sure everyone understands the risks that are inherent in a under-analysed and under-planned project. "We'll get right on it. Hopefully we can mitigate not knowing who the sub-contractor is and still end up with something workable."
  2. Bring stakeholders (including users) front and center to test solutions (user experience analysis, user acceptance testing). You will (of course) be trying to plan these things early in the project.
  3. Bring the leaders together several times per week (every day if possible) for briefings. These can be as short as 15 minutes per day. This can be a touchbase to make sure everyone (esp. you) knows what everyone else is doing/has been told by the VP.
  4. Track the rework and at projects-end have a lessons learned (ask the VP to attend). Have a clear breakdown of time and money for the re-work. At the same time, address UX analysis and UAT and make sure the VP understands how the solution was received.
2

Make All Work Visible

With issues like this, I like to reach into my agile toolbox and dust off my personal catch-phrase: "No invisible work--ever!" Let's look at how this helps in an agile context.

Re-work is Really Just "Work"

My sponsor is visionary but fails to communicate the vision clearly enough to allow implementation. This leads to a lot of unnecessary rework.

No worries! The sponsor is solely responsible for the success (or failure) of the project. You can help the sponsor make the project an eventual success by making sure that all rework is documented as work. "Rework" doesn't get special treatment; if it's a task that consumes time, money, or project resources, then simply document it and add it to the backlog. The Product Owner will then need to prioritize the new work items, perhaps shifting other user stories on the backlog as a result, and the team will pick the new work off the queue whenever it reaches the front (top?) of the backlog and is ready to be pulled into the next sprint.

This will eventually lead to questions like "Why is the project delivery date getting further out?" This is good, and it will enable you to have a discussion about process.

If the process works for the sponsor, then the process is fine. Even if the process is sub-optimal, if the sponsor breaks the process, the sponsor gets to keep both pieces.

Delegating Documentation of New Tasks

My sponsor communicates with team leaders directly without keeping me (or other project team members) in the loop. This keeps me from managing change in a controlled manner, it is hard just to keep pace.

Your team leaders are handling change. That's great! Since they're already being delegated to by the sponsor, all you need to do is delegate them the additional responsibility to update the backlog with all new work.

If the sponsor talks to Joe, and suggests that an embiggening feature be added to the project, then Joe is responsible for adding the new user story to the backlog. If Joe doesn't want that responsibility, then he needs to refer the sponsor to the Product Owner or Scrum Master. However, Joe must not be allowed to obligate the entire team, nor to spend time working on "invisible work." The work must be submitted as work to the team, and visibly added to the work queue.

Look at it this way: the process is only being bypassed because there's no clear benefit to Joe or to the sponsor for following it. If Joe or the sponsor realize that doing an end-run around the process means more work for them personally, then they will have an incentive to make the process work efficiently. On the other hand, if the process offers no value, then you should change the process until it does. That's a win/win for everyone!

It's ALL Just Work

My sponsor is a VP who honestly believes that some aspects of a successful project (e.g. having a continually justified business case) is his business and nobody else's.

Awesome! Since your VP has identified a business need, he should be happy to allocate team resources to the task. That means that time spent collecting data for use cases, writing proposals and specifications, and other related tasks should be added to the backlog.

If it's work that the VP wants to do, then by all means add him to the team and let him pull user stories off the backlog into each sprint. If it's work that the VP wants to delegate, then the team will pull the tasks into a sprint when:

  1. it's prioritized to the top of the backlog, and
  2. it fits within the upcoming sprint.

Since it's the Product Owner's job to prioritize the backlog, it's your job to refer the VP to the Product Owner if there's an issue with how the work is being prioritized. If the Product Owner agrees that updating a business case this sprint is more important than the sponsor's embiggening feature, then it's a value-based decision for the business. Everyone wins!

Cut Twice, Measure Never?

My sponsor is of the (all too common) type that wants work to start on a solution before an adequate plan (or even definition of what the solution will look like) is in place.

Wonderful! Work for its own sake can be very rewarding. Of course, if it's invisible work, no one gets any credit for it, and no one faces any consequences for failing to plan or design even that minimal amount that agile processes need to succeed.

The solution is the same as before: document all work. Building a new architecture because last month's solution was not well thought out? Add it as visible work. The unwise embiggening feature has caused the deaths of millions of your best customers? Add the cost of lawsuits, changing your identities, and moving to another country to your project's budget.

No matter what the result, good or bad, the process needs to have visible consequences to the entire organization. A good process will have net-positive natural consequences; a bad one will be significantly less wonderful for all involved. However, it all starts with making work visible.

Add some sensible inspect-and-adapt points such as bi-weekly sprint reviews and retrospectives, and you may find that "diving in" is a strategy that works for your company. A little just-in-time planning can be very effective.

"Measure once, cut once" is the epitome of agility. You might even get away with "cut once, measure once" most of the time. However, "cut twice, measure never" is just silly.

Summary

Most of my response has been from an agile perspective, but you can ultimately do the same thing with any methodology. Just make the work visible!

In the end, a good project manager is the shepherd of the project's process, not the poster child for its ultimate success or failure. Your main job is to educate the organization--including the project's sponsor!--on the current process, and to help folks adapt the process (or implement new ones) in ways that enable them to get the job done.

Protect the team. Educate management. Do whatever you need to do...but no invisible work, ever!

1

Document, document, document.

The only way to survive this type of sponsor is to document EVERYTHING, and then track it all.

Presumably you have an original scope, budget and schedule, or a set of requirements. Start tracking the burn of the budget and showing where more is eaten up due to re-work, miscommunication, unclear direction, etc. You're right in that he doesn't understand the value of a PM, but there are ways to subtly educate him. Show him where overruns are, or where you could have saved money (and consequently made him look good) throughout the project.

And make sure your team understands how managing a project works, so they understand how critical it is that they let know of conversations with the sponsor. You can't stop him from talking to them, but you can get them to let you know if he does.

Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.