Three Solid Approaches You Can Apply to Programs

Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.

When your customer lacks confidence in your ability to deliver solutions to their needs, what recovery actions can you take?  Here are three approaches that have helped turn around such situations.

Almost immediately upon joining as a program leader, you discover that your customer (an operating unit in the business) doesn’t appreciate what your team has accomplished, is dissatisfied, and lacks confidence in your ability to deliver solutions to their needs.

As a result, you awaken each day to face a mounting list of difficulties.  It’s near impossible to keep team morale high.  And every interaction with the business leaders is an exercise in frustration.  Talking more doesn't seem to help.

Is this situation salvageable or it is beyond help?

Start by ensuring that you understand the situation. A quick analysis and diagnosis can set you on the right path. Talk with enough people to understand the primary causes of dissatisfaction.  Gently probe to understand their perspectives.  Avoid making assumptions.  Rather, ask thoughtful questions to develop an understanding.

Let's walk through a situation I encounter frequently when joining an existing program:  The business leaders are disappointed with the long program schedules and aren't deriving much benefit from what the team eventually delivers.  They don't trust the delivery commitments made by the program.

Here are three approaches that have helped turn around such situations and have served to strengthen the partnership between the program team (which, strictly speaking, does include the business) and those in the business operating unit.

Periodically agree with the business on their priorities. Rarely does "the business" speak with one voice.  The programs I've led might have over a dozen business leaders involved, and their varying perspectives can be at odds with one another.  Partner with your business stakeholders to create a method of creating alignment on business needs and priorities.  Include the technology team as a stakeholder with an interest in controlling technical debt.  Commit the program to always focusing the team on these agreed priorities.

How did this help our programs? On multiple programs, I've partnered with the business to re-explore business priorities every calendar quarter.  Frequently, there is an influential business leader heading up this activity.  The key benefit here has been the alignment of business leaders on their collective priorities.  As a direct result, we decreased the complaints by those leaders whose organizations weren't receiving the attention (and deliveries) that they desired; having the business agree on higher, as well as lower, priorities gave everyone unambiguous clarity on the needed focus.

Smaller deliveries, more frequently. Nothing novel here, this is straight from the Agile Manifesto for Software Development (the first and third principles).  Even when the initial team reaction has been to object ("We can't deliver until everything is in place"), we've always been able to nurture a mindset of continuous product delivery and have been able to evolve the product with frequent deliver/feedback cycles.  While some product deliveries do take an extended development period, the many frequent deliveries serve to benefit the business sooner and build trust in the program team.

How did this help our programs? The primary beneficiary of this action is the business.  They realize value from the program team's efforts more rapidly.  This gives them more of an opportunity to experience new capabilities and conceive of further improvements.  The program team itself found that the deliver more frequently pattern was motivating and rewarding.  A nice, and critically important side effect is the natural creation of a close and trusting partnership.

Decrease the distance (knowledge and understanding) between the program team and the business, through job shadowing (Mo Berry has great insights about this distance). Job shadowing comes from the concept of a Gemba walk.  With agreement from the business leaders, each program team member spends time observing and learning how the product/system is used in operations.  This first-hand exposure helps them develop an appreciation for the business and how technology can help (or hinder) operations.

How did this help our programs?  Job shadowing has surfaced valuable insights that have influenced our product direction.  I encourage job shadowing by each person on the program team; on larger programs of hundreds of people, we’ve conducted job shadowing with about 30 members from the program team.  I ask participants in job shadowing to publish a short note on the program discussion board about their learnings so all can derive some benefit.

How do you lead programs in delivering value and building strong partnerships with the business?  What techniques have you implemented that have helped the program better support the business?