MAKIN 
Week one is listening, not designing.
We sit with the people doing the work and watch them do it. What a process document says and what actually happens diverge within about ten minutes of observation, and the gap is usually where the project’s real risk lives.
Write the current state down first.
Before proposing anything we produce a map of how the work runs today, including the workarounds. Clients often find this the most valuable artefact, because nobody had ever written it all in one place.
Week two is deciding what not to do.
Discovery produces more opportunities than any budget covers. The second week is spent sorting them by value and by how much they depend on each other, and being explicit about what is out of scope and why.
What you get at the end.
A current-state map, a prioritised change list with rough effort, a recommended sequence, and a fixed-price proposal for the first phase. If the honest recommendation is to do nothing yet, that is what the document says.
Before day one: what we ask you to arrange
A sprint can lose its first days to calendars and logins, so we agree the logistics before it starts. Each item below matters because the whole of week one depends on watching real work on ordinary days, not hearing it described in a meeting room. If any of it cannot be arranged, it is better to move the start date than to run a thinner sprint.
- A named sponsor who can make scope decisions and will attend the kick-off and the readout
- Time with the people who do the work, at their own desks
- Read access to the systems in use: accounts, CRM, spreadsheets, shared drives
- Copies of the forms, reports and templates people actually fill in
- A contact for whoever looks after your IT, even if that is an outside vendor
- A note of projects already under way that the sprint should not collide with
Days one to five: who we talk to, and in what order
Day one starts with the sponsor: what prompted the sprint, what a good outcome looks like and which constraints are fixed. We then meet team leads briefly, mainly to agree whom to shadow. On days two and three we sit with the people doing the work, and with whoever receives their output, such as accounts, dispatch or the customer-facing team, because a problem is often felt one step after it is caused.
Day four is the systems view: talking to whoever administers the tools about integrations, exports and anything held together by a scheduled job or a macro. Day five is a playback. We walk the draft current-state map through with the people we shadowed, and they correct it before anyone senior sees it.
What we write down while we watch
Observation notes follow the same shape every time, so that notes taken with different people and teams can be merged into one map at the end of the week. The aim is to capture the work as done rather than as described, including every point where someone steps off the official route to get the job finished. Each set of notes covers:
- Each step, who does it and which tool they use
- Where work waits, and what it is waiting for
- Every point where data is re-typed from one place into another
- Workarounds: side spreadsheets, personal notes, WhatsApp groups
- Exceptions, how often people say they occur, and who decides them
- Questions answered from memory rather than from a system
- What people say they would change, in their own words
Days six to eight: sorting what we found
Week two opens with a long, unsorted list of opportunities. We rate each one on the value it would bring, the rough effort to deliver it, the risk of getting it wrong and what it depends on. Dependencies drive the sequence: a reporting dashboard that relies on clean customer records cannot come before that clean-up, however visible it would be.
Day eight is a working session with the sponsor. We present the sorted list, including the out-of-scope column with a reason against every entry, and invite challenge. A disagreement at this point costs a conversation; the same disagreement discovered in the middle of a build costs rework.
Days nine and ten: the readout and the proposal
Day nine is for writing. The current-state map is finalised, the change list is put into its recommended sequence, and the first phase is scoped tightly enough to price. Day ten is the readout, to the sponsor and some of the people we shadowed, so the recommendations are tested against the people who will live with them.
Unless the recommendation is to wait, the fixed-price proposal for the first phase arrives with the documents at the end. Because it rests on what we watched rather than what we were told, its scope can be specific: named screens, named integrations, named reports. Where the first phase is smaller than you expected, the out-of-scope list explains why, and the recommended sequence shows where the rest would fit.
What weakens a sprint
None of these are technical, and all of them are easier to prevent than to fix halfway through. We raise them at the kick-off so the sponsor can head them off, because each one either shrinks what week one can observe or reopens decisions that week two has already made:
- Lining up interviews with managers only, so we hear the process document again
- Choosing the solution beforehand and asking discovery to confirm it
- A sponsor who misses the day-eight session and reopens the list at the readout
- Access that arrives in week two, after the observation window has closed
- Reading the out-of-scope list as a rejection rather than a sequence
When a different engagement fits better
A discovery sprint suits a process problem that crosses several teams. If the question is narrower, such as build or buy, which architecture, or what to invest in first, the Tech Strategy Consultation, which starts at ₹3,000, is the lighter starting point. If you are about to acquire, invest in or inherit a codebase, Technical Due Diligence, from ₹23,000, examines the code itself rather than the work around it. Both sit on the consulting packages page.