Meeting Expectations Means Embracing Change Throughout a Project

A few years ago, a client asked if I had any advice for how to set expectations. He was part of a team that hired us to build his company’s first app. As our primary day-to-day contact for the project, he was nervous that by the end of the project, the final deliverable might not meet some of his internal stakeholders’ lofty expectations.

I paused for a moment before I answered. At ArcTouch, we had grappled with the question of setting expectations for years - but it never really occurred to me how difficult a position it must be for him, our main point of contact. He was incredibly dynamic and sharp - but he was also early in his career and fairly junior at the company. 

During a strategy session with him and a few of his peers, we scoped an app together that everyone felt good about. It was one that would meet the company’s business objectives and aligned with the realities of their budget. 

“You know, I think you have already done a good job of setting expectations,” I told him. “But the trick is to meet expectations throughout the project. Because the expectations will change.”

For service businesses like ours, the primary enemy to meeting client expectations is the clock. A fairly simple custom app development project might take us three to four months - including design and engineering. Even over that project’s short timeline, things change. People change. Technology changes. Businesses and markets change. And, as a result, expectations change. 

So how do we make our clients happy from start to finish? We accept and embrace change with an unwavering commitment to an agile process and continuous engagement with stakeholders. Here’s how we address the two biggest challenges: 

Over the course of a project that lasts a few months, a company’s teams may change and responsibilities shift. The more people learn, the more their views of the world change. It’s also human nature that people adjust their priorities on a daily basis. Sometimes, they simply disengage from previous commitments. Here are a few scenarios we’ve encountered in our projects: 

- It’s not my job anymore: People change jobs. Stakeholders from clients shift roles within an organization - or they simply leave the company. Sometimes, a new appointment comes in mid-project without an understanding of the project history or business context. 

- The handoff: A client hires an agency and the internal lead thinks his job is done after the “handoff.” They believe the agency can produce the app without further input. 

- I changed my mind: A stakeholder may shift their thinking about the direction of an app or major features for any number of reasons.

- Slow-bleed disengagement: A company has an internal meeting with 10 stakeholders. Then, three to five project leads go off and hire an app development firm while the larger group disengages. The handful of primary stakeholders may go through a proper discovery session, but only one or two of them will participate in the project work itself - from kickoff through completion. 

While the scenarios here vary, the end result is similar; Expectations for the app diverge from the development process. After stakeholders become disconnected from the development process, the app may evolve but their expectations remain the same. Or, the stakeholders change and/or their expectations change but because they have disengaged from the process, their thinking no longer aligns with the app.  

The remedy for this human drift is simple, but like many things, it’s easier in principle than in practice. It comes down to accountability and repeat engagement. 

We insist that our clients include as many stakeholders as possible in our initial discovery session. In the example I discussed earlier, when a company may start with an internal gathering of 10 stakeholders, we’d expect five to eight to participate in the kickoff with our team. 

Even more important is having cross-functional representation. If there were four groups or divisions represented in the client’s internal meeting, at least one person from each of those groups would be represented in our joint discovery session - and each is held accountable for their group’s interests throughout the project.

The more difficult part is keeping those stakeholders engaged. We use an agile development process (more on that in a bit), with project milestones divided into one to two week sprints. With each sprint comes a release - and a download is made available for all the stakeholders to review. We ask for feedback with each release and that feedback is incorporated into later releases. 

The primary stakeholder needs to sign off before we move to the next release. While we don’t require every stakeholder to provide feedback on every release, we do expect them to monitor each release over the course of the project. As stakeholder expectations shift, the app shifts along with it.  

Having this larger cross-functional team continually engaged is also crucial when people change jobs. It’s a lot smoother transition when one person in group of eight stakeholders departs than it is when a single responsible stakeholder decides to leave a company.  

Over the course of a project, a lot can change that relates directly to the technical aspects of an application, or the market opportunity it is serving. Here are a few common scenarios during the course of development:

- A new competitor emerges. 

- New features are introduced in mobile operating systems such as Android or iOS. 

- An organization’s business strategy adjusts as the overall market shifts.

- The development team uncovers a technical unknown that impacts the schedule.

- User feedback on early releases steers the team to changing the scope of the app.

The result of any of these shifts impacts the direction or feature set of an app. This is why we almost never agree to a project with a fixed price and feature set, locked down from the beginning. There has to flexibility to adjust during the project to the changing business or technology realities that no one could have anticipated.

In our agile development process, after each sprint’s release we have a review of the previous sprint and planning for the next sprint. Anything learned in the previous sprint - whether a shift in business strategy, user feedback, or new technology - can be added to the next sprint or put into a backlog to be considered for later sprints. 

Each new sprint has three types of tasks: Bug fixes, planned functionality, and changed functionality. A change in functionality is something that wasn’t in the original definition, such as a new or enhanced feature that’s needed to remain on par with a competitor. This may or may not have an impact on schedule or budget. The team could decide to remove a different feature that now seems less important, or we might find that we are tracking ahead of schedule and can afford to add more features into the product without impacting the budget and timeline. 

With our agile process, we assume that there will be changes during the course of development. Because if we’re not learning from every release and not adjusting to changes to the market, then the app isn’t going to meet the shifting needs of the business.

Things Move Fast. Embrace Change, Don’t Fight it. 

You often hear about how important it is to get alignment at the beginning of a project. And it is a key to a successful project. But in my years of experience working for firms on both the hired and hiring sides for various projects, it has been rare for a company or stakeholder to be disappointed after an initial discovery meeting. If we could stop time and magically produce the app we conceive on that day, the app would be perfect. The alignment issues always come later in the project and typically near the end - and rarely have anything to due with expectations set at the beginning. 

In the eight years since the first iPhone was introduced, the mobile industry is starting to mature - but it’s still one of the fastest changing industries. Every year, Google and Apple introduce new operating systems with new capabilities. These changes set off a chain reaction of innovation from companies in the mobile ecosystem, leading new technologies and new experiences. The change is good - and constant. 

It’s a simple fact: The app you’ve defined today won’t be perfectly relevant by the time it’s complete. Even over the course of a brief project, there will be change. Embrace it and plan for it. Keep the core team engaged throughout the process with iterative updates. Use a process that allows the app - along with its stakeholders’ thinking - to evolve. 

Don’t just set expectations. Meet them. Every step of the way.