Tag: project management

I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…

The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…

Failure

It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.

Chaos

We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.

Confusion

One of the values for bringing interns into the organization is the fresh perspective they offer. Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that seeks alternative points of view. In this organization, everyone gets their own coffee.

Adverse surprises during a team driven project are about as welcome as whooping cough at a glassblowers convention. Minimizing the opportunity for surprises comes down to how well expectations are defined at the very beginning and how well they are managed during the course of the project. Unidentified expectations are like landmines in the project path. When they explode, it’s bad and the course of the project WILL change. Product owners can’t elucidate all the expectations a stakeholder may have, but with experience they can define the major ones. With practice and attention, experienced product owners can tease out all but the minor expectations that are often dependant on discovery within the project’s sprints.

Key to this skill is knowing the questions to ask at the beginning. In my experience, stakeholders rarely deliberately hold back their expectations. They just don’t know what they don’t know and it is the product owner’s responsibility to establish clarity around expectations. Intuitively obvious expectations rarely play out as such.

A few questions for stakeholders that I’ve found helpful:

What business problems do you intend to solve with this project?

What do you need to see to know the project is progressing?

What will you see when the project is done?

What is your availability commitment for the duration of the project?

How often to you expect to meet to review progress?

How long do YOU think it will take to complete the project?

To what extent are your functional groups integrated?

Describe your process from design to development to implementation?

Are there other stakeholders we need to know about and include?

What factors have helped and hurt success with past projects?

This is by no means an exhaustive list of questions. And they may even seem obvious. The answers, however, are almost never obvious.

I also find it effective to challenge stakeholders with scenarios.

What happens if we discover this project will take two months longer than expected?

What happens if we discover a desired solution is technically unfeasible?

How will you support us if we encounter significant delays from client deliverables?

Product owners need to keep pursuing clarity around expectations until they are satisfied they have a good understanding of how the people side of the project will unfold. This will go a long way to helping the development team handle the technical side of the project.

While stakeholders answer these questions, product owners need to pay attention not just the words stakeholders use, but how they answer as well. They need to be scanning for underlying assumptions that drive the answers. These often reflect relevant cultural drivers which can signal significant expectations seemingly unrelated to the project at hand.

For example, perhaps the product owner has established the expectation of a three business day turnaround for feedback from the stakeholder when asked to review periodic project deliverables. “We can complete our reviews within three business days and work to get them to you as fast as possible,” says the stakeholder somewhat hesitantly as he looks off into the distance. Where the pain begins is when the inattentive product owner discovers that, while the feedback may be ready, the client organization has a thick layer of compliance and the feedback is hung up in legal for an additional one to two weeks…every time. If the stakeholder’s responses reflect something less than 100% commitment, keep asking questions designed to surface underlying assumptions.

As each sprint concludes, and eventually the project as well, the savvy product owner knows their work with expectations isn’t complete. Retrospectives for each sprint, each release, and the project conclusion should make note of the expectations that were missed and consider questions that could have been asked that would have helped surface the surprise expectations sooner.

This is also an excellent time to consider if any of the existing expectations have changed or if it appears there may be new expectations emerging. Internal forces, such as changes in team composition, and external forces, such as shifting market demands, can significantly impact the set of expectations a product owner is tasked with managing.

If you expected to read these kinds of things about surfacing stakeholder expectations, then you’re probably an experienced product owner.