03 June 21 Lessons learnt from my maiden project.
What an exciting time to be alive! It’s your first opportunity where you’ll take the lead on a significant project. It’s time for you to be involved in scoping and delivering a larger piece of work and—as fate would have it—you’re the Front End Developer responsible for the delivery of the project.
It’s an exciting opportunity. It’s your chance to show off all that you’ve learned and put it in to practice. You are ready to interrogate, inquire, question, assume, conceptualise and imagine.
You tear through the client brief. You lead the conversations with the senior stakeholders. You are confident you know what needs to be done and the problems you are going to solve.
Fast-forward.
Now we’re in the midst of building the new website and you’re wondering how you got it so wrong. It seemed to be so simple when printed in black and white on your project plan but it is taking you four times longer than you predicted, even though you factored for unforeseen problems. When you finish the functionality, you pray that you’ve tested rigorously enough that the bugfixing isn’t going to drain the allocated time and budget.
Well, having just completed my first experience as the sole front-end developer on a project, I can’t profess to be an expert. I can however offer some reflections on my experience. This experience being only the first steps in a bigger journey. So, with that in mind, here’s four pieces of advice I’d give past me.
Spotlight the blind spots.
After you establish and validate an understanding of the problem that the project aims to address, often the next step is to formulate some constraints that will dictate how your solution is created.
This isn’t necessarily setting the ‘what’ but making some decisions that will guide the design, build and testing of the project.
Now, while it’s quite easy to start off understanding a project as the functional components that are going to be built—like a new home page, or a site re-skin for example—it’s important to recognise that this train of thought may not highlight some crucial activities needed to deliver a successful project.
Don’t get tunnel vision and remember to check your blind spots.
For example, in working with an ageing codebase, it might be worth updating some dependencies for future stability. This will require a notable effort of regression testing.
Another example is the use of different build tools. Getting up to speed in a new workflow will take extra time.
You’ll need to allocate time to browser and accessibility testing. There should undoubtably be some time allocated to minor changes requested by the client.
Depending on the technical maturity, size and tenure of your company, there could be a smattering of different approaches that have evolved through different project work. Investing time to ensure that you develop in the most optimal way is always going to pay dividends.
Call out and communicate assumptions.
There’s nothing worse than reaching a pivotal point of a project, where budget, deadline and scope have been locked in a joust for months, only to discover that some effort has fallen into the abyss of ‘I assumed they were going to do it’.
Yep, you don’t know what you don’t know.
Articulating assumptions goes against how our brain works when interacting with our environment—otherwise, we’d be completely overwhelmed with sensory overload whenever we’re awake—but it’s a definitely a skill we can improve.
It’s worth getting feedback about the assumptions that you often make and being mindful to raise them in discussions.
Everything from communication mechanisms and supply of assets and copy, to testing and triaging responsibilities can and should be articulated.
The interaction between your team, client, and any other external teams are the situations where you will have to be most prepared. You’ve spent enough time and have enough shared experience with your own team to likely have similar assumptions. This is certainly not the case with external third parties who may be contributing to the project. So, as Scar said in the Lion King, be prepared.
Generate feedback when there is none.
The old saying that ‘no news is good news’ doesn’t apply to digital projects. It’s more like the calm in the middle of the storm – things might be quiet now, but that’s because there’s potentially rough weather on the horizon.
If there are situations in the project that seem oddly quiet with feedback, it’s a good sign that you should find other ways to solicit it. Or, that the people required to give feedback need some prompts to get them thinking.
Having a robust process for design and build reviews throughout the project will alleviate a lot of pressure later. Feedback can be solicited from your other project team members, colleagues outside of the project team, or external stakeholders. These sessions are valuable for testing assumptions, defending decisions and refining your understanding; even if nothing changes with design or build.
If the sessions feel a little more on the timid side of things, think about how to put reviewers in the situation that they’re using the functionality.
This could be involve:
- switching out content and supplying different variations,
- adopting a persona and following a particular user journey,
- or asking for some anecdotes on how the functionality has been used in the past.
You need to get people’s brains in using mode rather than reviewing mode. If you do, you’ll solicit a lot more feedback.
Define ‘done’.
The officious bureaucrat isn’t exactly a celebrated position in our society. You know, the person who loves process, rules and technicalities. But, everyone needs a little bit of this predisposition when it comes projects.
Break out the vernier callipers and calculator, it’s time to get precise.
What you may find in your first projects is a lack of 100% doneness pervading to different packages of work.
It’s very natural in the face of uncertainty to shy away from making definitive decisions and taking definitive actions. However, this can quickly create an issue. Anything that isn’t fully complete comes to be seen like a prickle; one or two is annoying but relatively quick to deal with. Once those numbers bump up though, you can be stopped dead in your tracks.
An example of this is holding a client to an official ‘sign-off’ on designs. Don’t allow the decision to be deferred or implied. If you leave this open and unarticulated, there’s going to be some awkward conversations later down the track when things have been built as designed and they’re not satisfying a late requirement.
Look at opportunities to tick things off the to do list and have them actually done.
If there’s resistance, you might need to find some creative ways to move things along. Some common struggles are getting approval after design walkthroughs, or implementing changes to designs. When is the design finalised and ready for build? Will alterations after this constitute a change request? If the development of particular functionality is complete, articulating it as such will provide less grey area when it comes to scope changes and bugs.
Being definitive may be uncomfortable at times, but having the tact and finesse to entertain these discussions is a crucial skill for delivering successful projects.
So hopefully by now you’re a little bit more prepared for your maiden project!
While the above advice is certainly not exhaustive, my hope is that it will cause you take note of some red flags. Ultimately, your goals should be to learn from the process of delivering a project and gain valuable experience by doing. By approaching your experience with a growth mindset, you can set yourself up for personal development and career progression.
After all, the only unsuccessful project is the one where you don’t learn.