Customers Shifting Requirements

My process on when customers shift requirements mid-work. Thought it might be helpful to others:

Immediately scope out the work. Get an estimate for how long it will take you to do. Write a paragraph or so in a journal on what you need to do to get it done. This doesn't have to be hyper-specific, just enough to know the rough scope like how we do it in task poker. If the work can be done in under a day and doesn't have any secondary work required with it (ops burden, UI work, etc.), do the work. If the work takes longer than a day or could add more work outside of me later, push back.

About pushing back in detail/how and when to do it:

If they ask more than a few times or especially if they go back and forth on the same subject, push back. Never do work that undoes other work without conferring with the team and don't do significant amounts of work without re-addressing scheduling.

Sometimes, when pushing back, the wise thing to do is to confer with your teammates, manager and the PM first to come up with an action plan. This is especially true for requirements that come from groups that are less familiar with software development or who aren't very cooperative/helpful. It should be a goal of yours to build the highest level of trust that you can, but sometimes customers lack the knowledge to work closely with you. That is okay.

Don't explicitly commit to anything without talking with your teammates unless you're 100% confident the work can be done in a matter of minutes. If you tell the customers you're going to do it, it's set in stone. If you don't, you can always back away after a few hours and say "This is too much work to do ad hoc. Let's schedule it."

Customers are delighted when they find out you just took care of something for them and show them the results. Whereas if you give them an expectation, you'll likely either get acceptance on success or disappointment on failure. This is only for small requests from the customer though --  you need to set expectations for large projects or you won't get enough customer feedback, and you need to be fair to them in terms of letting them know how progress is going in order to build trust.

Always make sure the team is aware of anything you're working on, especially the PM. Sometimes, the customer and PM don't align and it's important to surface that before you start work.

Comments

Post a Comment

Popular posts from this blog

Using Kanban Boards to Stay Organized and to Stay Motivated

I often work with Trello or Notion as Kanban boards. I maintain tasks for everything that I do. This helps me keep organized when I'm working on a large number of tasks, or especially if I have ideas for tasks that I am not actively working on. It creates a clear, constant document of the state of the tasks I'm working on. And more than anything, it shows to me what I've accomplished and lives on as a constant motivator for me. Why Kanban Boards Matter for You and Your Team One best practice that anyone working on a large project should adopt is to have at least one Kanban board task they're working on at any given time. Kanban boards are a visual way to track progress on tasks, enabling you to see the status of each task and its associated details. By consistently updating your tasks on a Kanban board, you'll reap several benefits: Greater personal efficiency : As you wrap up your day or put a project on hold, having detailed information on your Kanban board task h
Read more

Low Level Design Part 1: Reading and Gathering Information

Start out your document writing day 1 with a long list of open questions. As you read documents, you should slowly grow a longer and longer list of open questions. Maintain this list and keep adding to it while you write the doc. Questions are often more important than answers as they represent unknowns you need to disambiguate. You will need to ask people for most of your open questions. This is okay and most engineers are very happy to answer such questions. In general, people will feel more complimented rather than inconvenienced when their expertise is requested. If you can't find an answer to something and don't know who to ask, ask your manager or a senior engineer on your team. What if no one knows in your team? Formulate your question into something brief and meaningful and post it in your org or company-wide chat. If your question is technical, ask it as a stack overflow question and link it in the chat along with your question. Link to everything as hyperlinks in the
Read more

Low Level Design Part 3: Estimates

You should include your task breakdown and estimates in the low level design in the appendix if it's available. Design your project with the idea of disambiguating hard questions in mind. Frontload as much ambiguity in the project as possible. Changes in estimates months in advance are preferable to ones right before the deadline universally. Usually, the best way to do this is to write a thin vertical of your project first and then start fleshing out the functionality after that. If you haven't worked with a library, platform, language, etc. your estimates on that topic will have low accuracy due to unknowns. You can reduce this effect with additional reading, especially of code, or by writing code using that library yourself. Call out everything that you don't know.  Low accuracy estimates almost always take more time to complete rather than less . If you estimate a task as a week, the shortest it can be is an hour. The longest it can be is infinity. This asymmetry means
Read more