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:
- it's prioritized to the top of the backlog, and
- 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!
