Meeting Client’s Expectations With Experienced Project Manager

I’m Daria Kozlenko, a project manager at NIX United. My team is working on an IT product with over 150 people involved. Numerous teams work on this product, including a team of 30 IT experts from NIX United. Other teams hail from India, Japan, and China. We all share the same release date and task backlog. Therefore, it’s critical to work closely with all the client’s distributed teams to avoid making mistakes.

I want to share my experience and describe the challenges we had moving an old legacy system to a new platform, and how we carefully honed the tools and mechanisms of dealing with customer expectations in unpredictable situations.

This article will be helpful to project managers, business analysts, technical analysts, and other professionals taking a PM role.

IMAGE: UNSPLASH

Why Did We Work In The Face Of Uncertainty

At the start of the project, we had a partially constructed team of Front-, Back-, and Client-developers, business analysts, and QAs, and an approximate estimate of how many more professionals could be required. However, there was no planned scope of work, accurate estimation, or release strategy in place. Furthermore, the project’s key people (Product Owner, technical project manager, and supervisor) were promoted and transferred to other projects inside the company. Making matters worse, the customer set an unrealistic timeline without consulting us.

“You should have stopped the project!” – people will say. But for us, the glass is always half full. We have been working with this client for a long time and have established trustworthy and respectful relationships. Therefore, we considered it unreasonable to create a damaging precedent, followed by the end of cooperation. Moreover, we believed that in the short term, we would resolve the situation.

We began by refusing to stick to the client’s deadline. Instead, we focused on the tasks’ t-shirt sizing and received a revised deadline that differed by only five months from the client’s initial deadline expectations. We also actively coordinated the design, investigating the requirements to detect any bottlenecks and other teams’ dependencies. We tried to minimize all the risks in the early stages. All of this was done in collaboration with the development team to engage in substantial dialogue with the client.

How We Acted

First and foremost, we informed the customer of the risk of missing his deadline as well as the possibility of unexpected dependencies on other client’s teams that we were unaware of at the time. Thus, we started preparing the client for possible changes right away. Then we engaged a new Product Owner for constant structuring and recordkeeping of requirements. Our main goal was to shape and evaluate the scope as quickly as possible.

Our actions made sense to the new PO, and he became a part of the process. We were still capturing our results in artifacts on an internal system for working with a shared knowledge base. We also engaged other teams with whom we have dependencies to talk about it.

We highlighted occasions that stopped us and kept us from moving forward faster during meetings with the client without losing focus on day-to-day progress. For instance, the client’s design. After all, without design, we can’t fully construct the frontend.

After we finished grooming, we created a new timeline that included all the mentioned risks. The client was not disappointed when he received the new timeline as he was aware of every move. In fact, he had been anticipating it! The client was a participant in the process, and at that point, the only thing on his mind was coordinating the new adjustments with top management. Together with the client, we concluded that our team needed to consider other possibilities for the stakeholders.

It was vital to step back from the project’s constraints and investigate ways to reduce the scope, expand the crew, and so on, as well as predict the client’s potential losses. We came up with three options, each with its own cost and impact. The customer used our presentation as a starting point and had top management approve the revisions.

However, the planning stage of data migration was a different challenge for us. It was insufficient to finish creating all of the old system’s features on the new one. So instead, we needed to determine which organizations would migrate to the new system and when they would do so. And so that no one is left out, the essential metrics are identified, and modifications may be reversed if something goes wrong. Due to the upcoming winter vacations and plans for Christmas, we had to restructure our data migration strategy and postpone the release, and as it was important to conform to the client’s capabilities and schedule.

What Conclusions Have Been Reached As A Result Of Working On This Case?

Always Tell The Truth, And Nothing But The Truth, To Your Clients

Perform an audit of the issues as soon as possible as it is the only way you’ll be able to come up with a new solution that works. You will accomplish this as one team with your client, both interested in a successful outcome. It would have been a failure in our situation if we had opted to remain silent. Don’t expect to earn credibility with the client by agreeing to unreasonable or dangerous terms.

Client-side Stakeholders Should Be In Sync With One Another

Renegotiate agreements. When many key people are making decisions, they may not communicate with one another. It’s your responsibility to bring everyone up to speed. You are greatly mistaken if you believe that everyone in the client-side team is a bold person who bickers with each other every day. Everyone lives in their own world and does not have time for “additional” tasks.

Any Agreements Should Be Documented In Writing And Backed Up By Artifacts

The client may understand numbers better than any other language. And every conversation should end with a call summary— a brief note outlining what you talked about, what you learned, what you came up with, and who is in charge of carrying out the next steps. If this isn’t done, everyone will only hear what they want, and they will remember more negligibly. As a project manager, your job is to reduce the likelihood of such losses.

So don’t be a slacker; take notes on everything that was said. Even better, record the calls with the consent of all conversation participants. That way, if you miss or forget something, you’ll always be able to listen to the tape again. I practice recording call summaries, but it’s not always straightforward, so it is better not to multitask in complex sessions that require intense concentration.

Take A Look At The Small Print

You won’t get much done unless you immerse yourself in the project. Unfortunately, neither plan the load by development direction, appropriately calculate timeframes, display the crucial path, or collect the correct statistics and plan subsequent activities.

As much as possible, immerse yourself. Don’t dismiss yourself because you don’t have anything to offer the development community. Moreover, on the other hand, don’t be scared to ask questions and make a fool of yourself. The PM may occasionally bring out nuances that no one else on the team has considered. And it’s all because your view of the problem differs from that of the development team.

Consider Your Schedule’s Reliance On Other Teams

It’s crucial to reconcile all teams’ releases and align your activities with their own rules and practices. No matter how uncomfortable it may appear, don’t be hesitant to address the issue head-on. For example, during one of our general meetings with a team on whom we had dependencies, we learned that they did not intend to include the functionality we sought in their release. We learned that the 100% scope we were expecting was far from the case when we explicitly asked what they would be able to cover. This team also informed us that they would not deliver the development build we had hoped to receive by a specific deadline.

Assess The Risks

It is hard to reach full potential at work. Therefore, both the estimate and the duration are set with a certain risk proportion. This creates a buffer that gives us room for maneuver. However, keep an eye on the percentage of scope creep in this scenario. It’s a bad reception if it starts to expand quickly. It means you haven’t considered all of the risks and have generated an incorrect estimate. As a result, you may need to create a new scenario, increasing the number of players, postponing the deadline, or cutting the scope.

Dashboards Can Be Pretty Helpful

Do nothing by hand, be lazy. Atlassian has already considered everything for you. The most important thing is to know what you want to track and which metrics can provide you with answers. In my opinion, more dashboards are preferable to fewer ones. You’ll discover which dashboards you don’t require as you use them.

Introduce Grooming Meetings Regularly, Fixing Up The Requirements

It’s not enough to groom tasks for the next sprint. Finish the entire release scope. And the sooner you get started, the better. By procrastinating and postponing backlog tasks, you’ll not discover all the hidden surprises sooner.

Everything Should Be Planned For Release, Not The Nearest Sprint

This is a natural consequence of the preceding advice. You should view the entire picture, not just a part of it. It won’t be easy to objectively assess how much your team can cover the client’s expectations. If you don’t have a clear view of what’s going on, it is hard to indicate the deadlines. Version Report with Release Date is a helpful tool in Jira, and you should give it a shot. I’m sure you’ll be surprised to see release dates in a more pessimistic overview of the situation.

Don’t Do Everything On Your Own Team

Sharing some functionality with other distributed teams may be more reasonable. If they have done the activity before, they may have more expertise. As a result, they may be able to complete these tasks faster than your team, which will have to spend more time delving into a new area of the code. Consider overall profit rather than discrete gap fixing.

Consider Dependencies And Consult With Architects From Other Teams As Well As Your Own

Other teams’ experts can point out what your team is missing, saving much time for the entire project.

Keep Track Of The Project’s Metrics

You must be aware of the performance of your team. Keep track of definite departures from the plan with each sprint. If you find yourself behind schedule, you’ll need to figure out how much work you’ll have to do, how quickly you’ll have to make it up, and who will pay for it. Sprint Reports in Jira provide tracking-velocity at the end of each sprint. I also recommend using the Sprint Health gadget and the Rich Filter by Status.

Keep Track Of The Scope’s Modifications

Of course, it’s always better if it’s automated. Make use of Jira notifications and dashboards. If you cannot set up the procedure on your own, you can enlist the help of the client or more experienced coworkers.

Be Open And Honest In Whatever You Do – Everywhere And At All Times

Keep the client updated on your progress frequently. With words spoken aloud and text sent via email/messaging. Also, keep in mind that any information, even the most basic, might be misunderstood. So make sure to explain even the most basic details as the catch could be hiding in plain sight.

I’m looking forward to seeing how our journey concludes in the current version, but that’ll be another story.

If you are interested in even more business-related articles and information from us here at Bit Rebels, then we have a lot to choose from.

IMAGE: UNSPLASH