how to manage changes and customer expectations

how to manage changes and customer expectations

I share my experience in organizing the RFC (Request for Change) change management process and connecting the customer to it. This helps not to be disappointed in the product, comparing expectations with reality, and eliminates situations when tasks arrive with deadlines “yesterday”. In the text, you will find step-by-step instructions for preparing for product design and development, as well as life hacks for solving possible problems. The article will be useful to those who work at the forefront of the development team: project managers, analysts and Product owners.

My name is Dmytro Letyago, I am a systems analyst at Outlines Tech. He has been in the profession for seven years: worked in retail, industry, engaged in state projects. Now I develop banking projects and run a personal blog, for which I record podcasts and collect useful information for analysts.

What is the RFC change management process?

RFC change management is the process of identifying, documenting, evaluating and agreeing new requirements for the development of an information system. It is useful for teams developing orders for an external or internal customer. In more detail, how exactly the process takes place, I wrote below.

Benefits of change management:
– Transparency
Weekly meetings with stakeholders, leads and the development team, which allows you to correlate expectations and remove questions about the work process. Stakeholders are actively involved in the project and understand what is happening there.

– Clarity of boundaries
Fixation of all the “wishes” of the customer, which prevents the final implementation from deviating from the initial plan and critically exceeding the budget. This excludes situations when you ordered a bicycle and received a moped for the price of a car. Like two wheels, a steering wheel, a seat, the vehicle goes from point A to point B, but something is still wrong.

My change management experience: stages and life hacks

We create a separate project in Redmine that is available to stakeholders and development leads. We enter all the RFCs with the customer’s requests into it. There, all participants track their status and progress.

Jira Software, Asana, 1C SPPR, Trello and any other task tracker are also suitable for managing tasks. The main thing is that there are functions:
– creation and grouping of requirements (tasks)
– Adding attributes: status, artist, priority, etc.
— the possibility of adding a text description and attaching files

This is how the project structure looks like for RFC management + the relationship with the development project is shown

The initial stage is the initiation of changes. The stakeholder starts the RFC task in Redmine, sets the desired deadline, prescribes a set of attributes such as: tracker, topics, descriptions. Various NPAs, feedback from users, wanted sponsors and so on can act as sources.

Next, the lead analyst or Product Owner conducts the initial analysis (follow-up), defines the implementation concept and estimates the top-level labor costs. All these steps are recorded in the RFC description.

Conducting CAB
Next, a set of tasks with an initial evaluation goes to the CAB (Change Advisory Board) – a council for changes. The composition must necessarily include representatives of all interested parties, except representatives of the developer.

There we make a decision to include revisions in the version, put the task on hold, or refuse production.

According to the results:
– Each RFC acquires a status (development, hold, archive);
– The analyst responsible for finalization is fixed;
– the term of submission of the statement and the term of agreement are fixed;
– all solutions are entered into the Redmine task.

Frequency of CAB: once a week, once in a sprint or as needed (when the RFC backlog is filled).

Connect the related team to the CAB and the project in Redmine, if it is involved in the integration work. So you will be in a single infofield and will track changes together without breaking communication. The paragraph is based on the experience of failures when teams could not coordinate 🙁

There are cases when labor costs are from a preliminary estimate. Here it is important to signal CAB changes in time. Frequent interaction with the customer, with the stakeholder, allows you to maneuver between the real situation and the preliminary assessment and manage the customer’s expectations.

Processing by an analyst
When the task receives a rich attributive composition, the analyst enters the work again. He processes the requirements and prepares the most formalized document with the necessary artifacts. That is, at the output after the analyst’s work, the same task comes out, only with attributes and additions: a prototype, a business process model, a description of use cases and a contract.

If the terms of agreement are delayed on the part of the stakeholder, this is an official occasion to postpone the execution of the task, if such conditions were discussed before the start of work.

But what to do with tasks that get on hold? In this case, we form an RFC backlog, which is useful to review on CAB once every two weeks. Example: such tasks include work that needs to be implemented based on the updating of legislation. When the date of entry into force of the normative legal act was moved to a later period.

After agreeing on the tasks, we can calmly plan the production process from sprints and form a release program. This is the topic of a separate article. The main thing is not to forget to record all the steps and organize a weekly CAB to discuss the tasks.

Here I am sharing a file with complete RFC life cycle and action algorithm including timeout.

Instead of output

Of course, the introduction of something new is always accompanied by skepticism and resistance from the participants. However, the result is worth it: as soon as the process gets on track, a lot of uncertainty will be removed and a favorable atmosphere will be created for long-term cooperation with customers.

Glad to answer questions in the comments and discuss project situations.

Related posts