A great approach to problem solving - I appreciate the Side Kick approach discussed in this article. As PMs (or as Scrum Masters) we solve problems, remove roadblocks, and support our teams as much as possible. Ayse Birsel's article brings up interesting ideas on how to prepare for the worst.
Let’s see if you’ve heard this before in your office.
“Business people don’t understand anything about technology!”
“Why can’t IT deliver faster?”
“Leadership needs to share their vision!”
“IT just needs to do what they’re told, they don’t understand the business!”
And this gem of a conversation:
Business: “When is my project going to get done? I need to know what to plan for the marketing email.”
IT: “We need to define your requirements to get a date. What exactly do you need?”
Business: “How can I plan what I’ll need if I don’t know when I’ll get it?”
IT: “How can I tell when you’ll get it if I don’t know what you want us to build?”
The truth is that we all have the same basic challenges when it comes to projects. The struggle between clear requirements and value statements, accurate estimates and completion dates is ongoing.
Every company I’ve worked for (which I admit is not many comparatively) has had these issues, these discussions. And every company I’ve worked for has argued at some point that the conventional wisdom of the industry works great for everyone else, but “we’re special, we’re different, we’ll need to try something new.”
Months (maybe years) go by, consultants are consulted, in-house resources spin up special cross-functional analysis teams, leadership weighs in… and in the end everyone comes to the consensus that the conventional wisdom really is the way to go – maybe they should have just started there and made a few tweaks to align with organizational specifics.
So why can’t we learn from the best practices of others?
I don’t have an answer here – but I do know that in every case that I’ve experienced, there is an individual or a small group of people pushing for the quick and simple approach from the beginning.
Often they’re too low level to be heard, which is to the detriment of the company. Leadership teams are great, but they’re pretty far removed from the actual work that keeps things going. The further down an org chart you get, the more likely you are to find small, practical solutions to real problems.
Some blogs offer advice or answers – this one raises questions.
When I find myself in this position, I try to remember: “Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.” - Margaret Mead
"You Can Buy a Man's Time..."
“You can buy a man's time, you can buy a man's physical presence at a certain place, you can even buy a measured number of skilled muscular motions per hour or day. But you cannot buy enthusiasm, you cannot buy initiative, you cannot buy loyalty; you cannot buy the devotion of hearts, minds, and souls. You have to earn these things.”
Harsh, but true. No one really cares about whatever change you’re trying to champion, they care about their own.
Let’s look at an example
The factory in which you manage a production line is purchased by an overseas company. In order to allow easier communication between your location and the main office (now an ocean away), the new main office is shifting their hours one hour later, and your factory is shifting to one hour earlier for all standard operations. They’re asking that your day now shift from 8am-5pm to 7am-4pm.
Overall, it makes sense – now you’ll all have overlap hours until after lunch, opening schedules for calls and efficient communication with the main office. Sounds great!
Your leadership rolls out a series of change communications, discussing all sorts of positives that focus on the people rather than the company:
This is a great start! Leadership is considering the needs of their people, not just those of the organization.
But what about you?
The official ‘positives’ are pretty neutral for you. And then there are the negatives:
The new schedule will throw off your whole routine (not to mention your dog’s important schedule).
In light of all of this happening to you, do you really care about the positive changes for other people? For the company? Nope. You don’t care at all.
So what makes you think that anyone cares about your change initiative?
Nothing I’ve said here shows that the leadership team in our example did anything wrong. Their goal is (and should be) to do what’s best for the company. They also created a communication plan and made an effort to talk about positive impacts for their employees. This is all great.
What else could they have done?
Perhaps these would work for the overseas office, but you work in a factory and manage a production line. In that role, you have to be onsite when the line is operating, so a flexible schedule isn’t an option. You already dress fairly casually, and you always have to follow safety regulations, so it’s unlikely that a dress code change would be impactful to you. Job sharing could be an option, but that would involve reducing your hours (and your paycheck) by half, which is not terribly practical for you.
So what can your leadership really do for you? They can listen. They can respect that this adjustment is hard for you. They can give you plenty of warning so it doesn’t happen suddenly.
And most of all, they can let you choose how you will proceed.
When you’re rolling out a new change initiative, you can take every possible step. You can send out surveys and carefully plan communications. You can implement training and offer incentives. You can listen and talk about options and answer questions and provide any number of support tools.
In the end, change is individual. It's not about the new hours or any new initiative; it's about the direct impacts on our lives.
In our example, perhaps you could shift your poker game to earlier in the evening, start going to the gym after work, and deal with a few weeks of a confused dog (he’ll forgive you, you’re sure of it).
Or you could look for a new job. That may seem excessive to some, but what if your poker game is the only time you see your best friend, and she already arrives late because she works until 6pm? What if your gym is so full after work that a workout takes twice as long or longer? What if your dog…? Ok, you can probably deal with the impact to your dog’s schedule.
The key takeaway is that change is individual, and each individual decides how to deal with it. No matter how effectively you roll out a change initiative, some people will simply not want to come along with you. And that’s OK.
It was the best of projects, it was the worst of projects, it was the age of empowerment, it was the age of hierarchy… I had better stop before Charles Dickens* gets annoyed with me.
Imagine two projects:
Now imagine a (likely) scenario. Perhaps a priority shift comes from leadership, or a new technology erupts as the hottest thing on the market, or maybe a critical privacy law changes dramatically.
Any one of these changes (and many far smaller) can wreak havoc on a project – and none of these scenarios are outlandish.
How do the two projects we imagined handle these scenarios?
Let’s start with the Waterfall project.
The team spends a full six months compiling requirements, interviewing stakeholders, and documenting what they plan to build; then another three to six months planning tasks, requesting resources, and laying out baselines for schedules and budgets. Then the project moves into execution where it’s scheduled to stay for several years, closely monitored and controlled. Stakeholders are happy to have clear expectations set.
It’s a year into the project’s execution (two years since the kickoff), and with minimal adjustments it’s on track. There have been a few tweaks, but everything has been falling well within established tolerances.
Enter: The Change (in this case let’s assume it’s an update to privacy law.) There is a long list of things to consider:
Each of these considerations has a list of tasks that comes with it, including implementing the changes of course, but also communication, key decisions to be made, research, and more.
As PM of the Waterfall project, you know what to do. You pull the key people from your project together to submit a concise change request, plan an approach, and assess the impact of the work (possibly multiple assessments, if you have several options to choose from). This effort takes several weeks, partially because a key leader is on vacation for a week and three other stakeholders are at a conference the following week. The final decision can’t be made until everyone has had the opportunity to review the details and weigh in.
Then it takes a week and a half to plan the approach that’s been decided on, and several more weeks to adjust the rest of the project timeline to accommodate the new additional work.
By the time work begins on the new change, a few months have passed and the overall project plan is impacted as well. Hopefully the process didn’t take longer than your legal compliance timeline.
On to the Scrum project.
The team sketches out a high level structure of what they’re going to build, and prioritizes the work based on agreed upon evaluation criteria (criticality of the capability to the business, complexity, technical dependency, perhaps others). They dig into the first priorities and write stories for developers to work on; staying several weeks ahead so there is a steady stream of prioritized requests for the rest of the team to build.
Execution is underway about two months after the project was kicked off. The full picture still isn’t defined with complete requirements, but the team continues to deliver the highest value capabilities and stakeholders are happy to see tangible results early.
At the same time as before, about two years after the kickoff, The Change comes (the same update to privacy law). The same considerations and tasks get added to the project – after all, it’s the same change we’ve already looked at.
Managing change in a Scrum project is a team effort. The team pulls together to assess and prioritize the needs that come from this legal change. You’re all empowered to make project decisions, so you get to work on the most critical pieces as soon as possible, and add lower priority items to your backlog to work on as needed.
The team is underway on the second high priority item when your leadership team determines that they are choosing a third party partner who is already compliant with the new regulations. A portion of your project, as well we all of the work done on as a result of the privacy law update so far, now need to be undone so you can integrate with the new third party partner’s systems.
By the time integration work begins, a few months have passed and the overall project is impacted as well. Hopefully the process didn’t take longer than your legal compliance timeline.
What does it all mean?
Both approaches, Waterfall and Scrum, have pros and cons. Waterfall is predictable and manages expectations effectively; Scrum is quick and easily adapts to change. Waterfall takes a comparatively long time to plan and adjusts slowly to changing requests; Scrum is difficult to communicate clearly and plan for long term.
Both options have a time and a place; neither is ‘the right way’ in all scenarios. Trends show that successful companies implement with the right methodology at the right time, often blending structure and speed to meet their needs.
So how could both projects have been more efficient?
In short, both Waterfall and Scrum can learn a little something from each other. As PMs we learn and use these standard methodologies, but perhaps the right answer is to create our own. Each company, each PMO, will have different needs and inputs. What if rather than looking at these two options as disparate, we instead view them as two ends of a spectrum? Or perhaps two tool boxes? Then we could find the right answer for our needs somewhere in between – taking pieces from each methodology (and so many others) to focus on the needs of our projects and teams.
To wrap it up, I’ll bring it back to Charles Dickens* (even if he might get annoyed).
It is a far, far more balanced project that I run, than I have ever done; it is a far, far better project close that I go to than I have ever known.
*Apologies to Charles Dickens and A Tale of Two Cities. They both deserved better.