This job would be great if it wasn’t for clients, amiright?
One of the first challenges on a client project is scoping out what the client wants. What counts as a must have to go live, and what counts as a nice to have in the future. We start with a minimum viable product, and then go from there, based on budget, time, etc.
To do this we need to get to know the client, the business, the stakeholders. Their day to day needs as well as their plans for the future. We have the technological background and ideas we can bring to the table, but we need to ensure our suggestions are relevant and useful.
We build a relationship to build and handover a good project to them. We do this in a number of ways. When the commercial team hands a project over to production, we get a handover that give us an idea of how the commercial team see the project, and any relevant documentation; pitches, etc. We get an overview of who our contact points are, and feel for what the client expects, and what the relationship is like.
We then set up workshops with the client. These are whole or almost whole day affairs that bring the production staff and client together to meet and get to know each other.
The hardest part of getting to know a client’s business is getting the details that the client feels are unneeded or obvious. They sometimes feel that they don’t need to state what they see is the obvious. Most of the time we catch it, because sometimes it’s obvious, but sometimes it’s not and things get a little hairy.
Talking about all this plus an intro to how we work, and who the project team are can take all day, so after all this, we go away. We design a homepage, do some wireframes of internal pages, and any particular functionality (checkout pages, landing pages etc), start populating the backlog and getting the first sprint of basic stories together. We can do this fairly early as the basics are fairly generic depending on the type of project – the base install and theme always has to happen, then content types, the ecommerce side, things like that go into sprint one.
Then we have our second workshop, reviewing design, wireframes, and our plan. We email and talk between these, but the workshop is where we expect to make the most headway.
The wireframes and designs almost always change but we do them so we’ve got a jumping off point. We can illustrate our thinking and see where the gaps are. The wireframes are good to illustrate high level functionality, and help the client envision how information will look and flow. They’re a visual prompt for questions and discussion. This helps us get more granular information and fill in the gaps between our ideas and their needs.
At this point we expect to be in a good place to refine the backlog and tickets more, and start the process of signing off AC for the first sprint, and start planning the second sprint. The client knows the team they’ll be working with, and we’ve started to build that relationship of trust that’s needed when building a project for someone.
We plan a lot upfront, because it’s worth it, and we get good relationships with our clients, and the whole team has input into a project as early as possible. This means we’ve all bought into the project, and are invested in it. The client and stakeholders are faceless, and neither are we. We’re a team, making the best product we can.