A full first year of contracts – I am blessed

Let’s start with this post from a year ago today (at time of publishing)….

https://www.linkedin.com/posts/charandip-sidhu-421a1a9b_today-marks-the-end-of-my-three-year-adventure-activity-6436273552558690304-ZQo7

When I decided to go contracting, I felt the time was right. I had been at Department for Work & Pensions (DWP) for a few years on various projects. They were a mixed bag, some were technical, others were design focused. I had learned a lot, now it was time to step up, apply that learning and become the expert Business Analyst that I always knew that I could be and be it in a new organisation.

Did I bite off more than I could chew? I had a big network in the north of the country, both professional and personal. I had spent almost three years living in Leeds and Sheffield. I was living at a place called Clarendon Quarter, a key workers scheme, with young professionals and like-minded people. It was a new building, so I set up a WhatsApp group. In time it had over 60 people, all meeting for the first time and still going strong today. If I wanted to blow off some steam, all I had to do was walk through the door. Even at work, I was the ‘social secretary’, I could organise a work do with ease. For lunch, pie and a pint, in the evening a pub crawl with many… many shots. I organised the Director’s Christmas party, it was a great event, surrounded by hype. I had a reputation that I took for granted and now I was moving to Southend, where I knew nobody.

Now that you’ve got some context, I want to discuss a few topics that can summarise what contracting has bought 🤐, I mean brought for me 🤣. These include:

  • Summary of my contracts
  • What I have learnt
  • My lifestyle
  • Key activities/achievements

Capgemini and HM Revenue & Customs – Southend-on-Sea

It was my first day on the project, the team was made up of a Scrum Master, DevOps, three Full Stack Developers, a QA Tester and another Business Analyst, in addition to myself. It was a technical piece, part of the Brexit programme and our ask was to replace a piece of middleware, whilst adding some validation enhancements. Every project I had been a part of up until this point in my career, had a front end. The progress was always visible, easy to demonstrate to Product Owners. This was going to be different, but I wasn’t prepared to fail, not at the first hurdle, in fact not ever. This being said, it was going to get harder before it got easier, not just because of the challenge, but because of the circumstances.

Like I said before, my professional network and my regular personal network was in the north, I was now in Southend and loneliness had begun to kick in. I was losing motivation, for the first time ever, I didn’t care. This should have been the best time of my life; I was supposed to be reaping the rewards of years of hard work. The late nights, the extra reading on agile methodology, software development and business analysis which was my focus over the last few years. I was twenty-six and in terms of my career, I knew I had come along way, all I had to do now was sustain it.

How could I ‘obtain’ happiness, so that I didn’t ruin the chance that I had been given? I knew that software development, particularly in government was a small circle and I needed maintain a solid reputation. If you know me, you know I’m an extravert, I crave human interaction and I try my best to keep people close to me. My undergraduate degree was at the University of Northampton, in the south of the country and I’ve always kept in touch with a group of really good friends. I also worked on projects with a few people that were now based in London and its surrounding areas. Liverpool Street was only an hour from Southend station, so we organised a few get togethers, when I was these people, I was loving life!

However, I was still undertaking a weekly drive to get to Southend from Wolverhampton. Four to eight hours in the car, twice a week, yep that could be intense if I wasn’t going to be in the right frame of mind. This is where I realised that I couldn’t always use people as an escape, I needed to be happy in my own head. How could I turn time with myself into positivity and motivation? The answer was music! Subconsciously I must have been preparing for this for years, my playlist was full of this, I felt the energy, lyrics connected with me and spoke to me about the situation I found myself in. J.Cole led the charge, with tracks such as Immortal, New York Times, Neighbors, A Tale of 2 Cities, Love Yourz and his KOD album. The universe even aligned nicely to release a couple of great albums such as Carter V (Lil Wayne) and B. Inspired, by Bugzy Malone.

No such thing as a life that’s better than yours,
For what’s money without happiness?
Or hard times without the people you love
Though I’m not sure what’s ’bout to happen next
I asked for strength from the Lord up above
Cause I’ve been strong so far
But I can feel my grip loosening
Quick, do something before you lose it for good
Get it back and use it for good
And touch the people how you did like before
I’m tired of living with demons cause they always inviting more

(Love Yourz, J.Cole)

Now after my drive to Southend, how could I continue with this theme and ensure I had a good week filled with positivity and progress? What I did was:

  • Change my diet
  • Start running along the sea-front every morning
  • Joined a new gym and banged weights in the evenings
  • Turned colleagues into friends (this was the easy part; my personality was still as addictive as ever)
  • We went for lunch every day and the pub after work on occasion
  • Meditation and prayer in front of the sea – It’s always important to be humble and thankful
  • Talk to my northern connection, we still kept in touch
  • Booked a holiday in Marrakech for the end of my first contract, a story for a different day 🙄

I haven’t talked much about my weekends because that was the one constant throughout my entire journey, Sheffield, Leeds or Southend. Wolverhampton was where my family and childhood friends lived, they were always here for me and every weekend I looked forward to seeing them.

It wasn’t all smooth sailing from here on out, but I learned to use the fire that was lit inside me. I was ready to make a success of this contract and I was determined to win, I told myself, where I couldn’t win, I was going to learn.

I was sold the challenge on the promise of agile. I felt inclined to try to implement good agile practices, which to be fair, I had some success doing. I led on sprint reviews, embedded three amigos and backlog refinement. I worked closer with the programme Business Analysts, rehashing user stories and implementing Behaviour Driven Development (BDD) acceptance criteria. I used BDD as the main method for explaining our sprint progress to non-technical Product Owners. It’s written in plain English so anybody should be able to understand it.

A large part of my skill set was used working closely with the Tester, I learned about XML and Xpaths and used tools such as ‘Xpather’ and ‘XMLSpy’ to come up with acceptance criteria. This would validate the new, replacement microservice that we were building, against the schemas for the microservices that we were integrating with. I further developed my technical understanding during this contract and understood more about how microservices could talk to each other through XML payloads. In addition to this, I learned from the team about how BDD is used in practice, where it is used in step definitions and how it integrates with gherkin and cucumber scripts.

I mentioned, there was another Business Analyst on the team, on a personal level we got on very well. However, he and I were from two very different schools of thought. He was a strong advocate of documentation and I was always promoting the value of ‘the items on the left’. We had many discussions about agile vs waterfall, and we disagreed heavily on the ask to retrospectively document what Developers had already built. However, I’m glad our paths crossed because on my current project (that I will discuss later), the value of documentation is paramount to the business analysis strategy that I have implemented, for a time critical piece of work.

Difrent & NHS BSA – Newcastle

It was time. Time to go back and reclaim my throne as King of the North! A 409 mile, all round weekly trip. No excuses this time, it was NHS Jobs, an agile project, Government Digital Service (GDS) even. The team were in funny place between discovery and alpha and they were looking for someone to help embed good practices to help build the service right, in turn enabling them to pass their alpha GDS assessment. They also needed a Business Analyst, that was not only familiar with design, but also with development at pace. This is where I could thrive and now that I had found myself again, I was determined to smash it out of the park!

NHS Jobs had a large team. A number of Developers, Testers, all of the good stuff in terms of Users Researchers, Content Designers and Interaction Designers. They had a Business Analyst, an Architect, Project Support staff and a Delivery Lead. There was also a Product Owner, Service Owner and Subject Matter Experts.

NHS Jobs was being rebuilt from scratch and being brought in house. There was a current service, with a supplier whose contract was ending. We had two work streams at the time, a candidate stream and an employer stream. There were two prototypes to align with this approach, which covered the functionality that was included on the Minimum Viable Product (MVP) roadmap. Each workstream was to include a Business Analyst, a User Researcher and an Interaction designer. Of course, we didn’t want to design in siloes, therefore each stream should knowledge share and assess any impact on each other through regular collaboration. The MVP focused on the bare essentials, the intention was to do enough user research and produce iterations to validate our designs as well as our ‘user needs’. Bearing in mind, there was also a team of ‘hungry’ developers, we needed to do this at pace.

I was the Business Analyst leading on the candidate stream. I had come into the team at a point when a lot of discovery work had already been done. Therefore, I didn’t want to set the team back by asking for extensive upskilling or lengthy discussions. The User Researchers had already done a great job by producing comprehensive user research reports and there was a full confluence library of information should I need to access it. I’m not suggesting that I didn’t ask any questions, or the team didn’t help, of course they did. I was just keen to ensure that I was using their time wisely, being new to the team, I could be a fresh pair of eyes, rather than a burden to carry forward.

My approach was to use the MVP roadmap and the candidate prototype to extract all of the ‘user stories’ that we would eventually want to develop. These would be documented on JIRA, then exported to confluence. We could then link any user research comments to the corresponding user stories and prioritise them in what became weekly backlog refinement sessions with the Product Owner. When we were prioritising the user stories, we would decide on three things:

  • Were the comments in scope for our MVP?
  • Did we need to produce further design iterations?
  • Did they test well?

Based on the answer to these questions, we either deprioritised and recorded comments on a post-mvp backlog, produced iterations and tested further or began the process of creating ‘dev ready’ user stories. I’ve been working with developers for years. It’s important to ensure they have early visibility, keep engaged and on-board throughout the design process. This allows them to highlight any blockers and come up with alternative suggestions, but also allows them to understand the user journey to a greater extent.

At the ‘dev ready’ stage, I began to define acceptance criteria, once again using BDD. When the acceptance criteria are defined, the three amigo’s session can take place. This included me as the Business Analyst, at least one Developer and a Tester. For the purpose of this blog, let’s assume the Developers are happy with the stories, because let’s face it, they’re my stories 😜. At this point, the stories can be demonstrated to the Product Owner. I would do this by talking through the BDD acceptance criteria and the prototype screens. When the ticket is signed off the user story can be prioritised into a sprint.

We presented this approach to the NHS BSA during one of our show and tells. It went down well and there was further interest from other BSA teams that were wanting to adopt a similar approach. We handed out these leaflets, which provide a diagrammatic representation of our process.

Another big piece of work I did whilst on the NHS Jobs team was a service design map. I worked with our SME and iterated it with the team. It was good to have one of these to ensure that we all had a shared understanding of our user journey. It demonstrated the parts of the process that would be handled by a live support team, what would be developed during our MVP and the parts of the journey that would be completed offline.

Now in terms of culture, Newcastle was amazing! The team at Difrent was amazing! The client, NHS BSA was amazing! A big city again, a younger, more sociable crowd than Southend. I decided to rent a flat rather than staying in hotels. I knew this gig would be six months or more. As a team, we all got on really well, this was apparent by our willingness to engage in extracurricular activities together, usually at the Quayside Wetherspoons. This is where we discovered Tequila Rose, or Tequila Rosé as we subsequently renamed it. It became the theme of many… actually all of our nights out. Whether it was inside or outside of work, this team knew how to give it 100%. I still keep in touch with many of them, I know I will for years to come. My true fans 👊.

This is probably a good point to mention, this contract was where the #forthefans movement really gained momentum. I introduced it as part of my first blog, which you can read here:

Design #ForTheFans

Despite all of this good stuff, I decided that around the MVP window would be a good place for me to move on. The reasons for this were:

  1. It had dawned on me that as tough as it seemed at the time, I made some real progress, in body and mind during my Southend contract. If I continued on the path I was taking in Newcastle, I might have easily reversed that progress.
  2. I hadn’t been used to so much travel, it would often take a full working day, on top of a full day’s work to travel up and down the country.
  3. I felt this would be the least disruptive time for the team, for me to move on. Post-MVP, a replacement could come in, pick up something new and take the team forward, with minimal disruption.
  4. A new contract outcome opportunity came up, still with Difrent, where my previous project knowledge/experience would be invaluable.

Difrent & Department for Work & Pensions – Blackpool

So last year, in relation to DWP, I said ‘I hope to find myself back here in the future’…. spoiler alert, as of May this year, I’m back! Thanks Difrent!

The project that I am now working on Electronic Exchange of Social Security Information (EESSI), is one that is close to my heart, it’s the first project I was ever a part of as a young Business Analyst. Difrent have won the outcome to make it accessibility compliant, and that’s where I come in. If you want to read some background on the project, and also learn a bit about Storyboards too whilst you’re at it, I wrote a blog about it which can be found here:

Bringing scenarios to life using ‘Storyboards’.

This contract was where years of networking paid off, a powerful tool. When I was leaving DWP the first-time round, I sent an email to the colleagues I had worked with over the years, thanking them for being a part of my journey. It just so happens, this included users, probably a dozen of them, that I had previously built a rapport with on EESSI. When we started on the project this May, for whatever reason, we were finding it very difficult to access users, resulting in obvious frustration for our User Researcher. However, I already knew users of the service in Blackpool, Preston and Newcastle, which were the main locations that we needed access to.

Funny story actually, I used to test with two users on a weekly basis in Newcastle. When I arrived, there would be a cup of coffee, a biscuit on a paper towel and a sharing bag of sweets waiting for me. If, on the rare occasion, I hadn’t eaten the sweets by the end of the day, they would pack them into my bag, whilst wishing me well for my travels back to Sheffield. I was genuinely excited to be seeing the both of them again. A few weeks in, I had made contact with a pool of users, caught up and reminisced about old times and introduced the User Researcher. There we have it, we now had regular engagement with users again.

The challenge wouldn’t stop there, our remit was to make the application accessible, we understood the value that user research could play in this. On the other hand, we had to be strict with what an ‘accessibility’ enhancement was, and what could go on the backlog as out of scope for this particular piece. Time was also against us. In fact, this is my current project and time is against us. I wanted to build up a high-level picture of what the service looked like in 2019, I already knew a lot about it, but three years have gone by since I last worked on EESSI. To do this, I conducted analysis of the current system, developed by the European Commission. I then extracted high-level epics that we needed to consider when making the portal accessible and added them to JIRA. We could now link any stories/tasks, that we take forward to the epic around the existing solution. This allows for traceability and will provide context to the Product Owner when we demonstrate our features.

The analysis, along with some previous assumptions that were made, showed that a high proportion of the effort from a BA perspective, should focus on the forms within the service. It was key to concentrate a lot of effort on this as it is the most widely used part of the service. In addition to this, the forms are numerous, upwards of 400. To make these accessible would take time, under any circumstances. This is where I realised once again that previous contacts could pay a key part in saving us time. Somebody could surely help point me in the right direction, with work that may have happened over the three years since I left the project. I frequently catch up (over lunch, what else?) with the previous Lead Business Analyst, who has a wealth of experience. She talked through at a high level the different components that the EESSI forms have and she suggested reaching out to a European Commission contact, that I met out in Budapest and is still involved in the project today. When I did this, the conversations (and documentation) that ensued, literally handed us a ‘golden ticket’.

I was given access to a review portal as well as the European Commission SFTP server, which contained in depth documentation on the EESSI System. The ‘golden ticket’ was an entity relationship model of the entire application, created using Unified Modelling Language (UML). Every form is documented, as well as every component that is used to construct it. I have regular chats with our lead Developer and was beyond excited to show this to him, my excitement was reciprocated. We agreed that this documentation was going to be pivotal to the success of our project.

As a team we decided to create a portal and integrate with existing API’s, making it accessible through a brand-new front end. In order to achieve this, for the forms at least, understanding the data model would be crucial. It was at this point that I was thankful for meeting the Business Analyst on my Southend project. We disagreed heavily on the value of documentation, but we had a number of conversations around it and I understood more about UML through discussions with him. In doing so, I understood where it would be valuable and now knew how to apply it on this project. I went on to conduct a knowledge share session with the rest of the team, talking through what this model was and how we could use it as the central pillar of our business analysis strategy.

Now that the direction is largely defined, the hard work begins. There are basically three types of component:

  • Cross cutting
  • Sector specific
  • Form specific

The bulk of the business analysis task is now to analyse each form, understand which components are being used, whether there are any child components within them and their relationship to each other (0..1, 1..1, 0..*, etc). In turn we will build up a library of components, with the intention of matching validation rules for the existing application API’s that we are integrating with. As this component library is being defined, the work to stitch them together into full forms, broken down into accessible pages, using GDS style patterns can begin. When the analysis on each component is complete, it will be added to JIRA tickets. The information contained within them will be:

  • The component, including the relationship between parent and child
  • Any validation, including enums and code patterns
  • The forms it is used in, so the Developers can route the components accordingly

When we get to this point, the business analysis work on the ticket is largely done. I would now assign the ticket to the interaction designer, and write a comment to say, ‘ready for UX’. The interaction designer would mock up the screens for the component and hyperlink any GDS style patterns that are used. We can then have a three amigo’s type session with the development team, at this point we should have all of the information required to mark the ticket as ‘dev ready’. Of course, this isn’t the ideal way of working, a production line has no place in an agile working environment. However, we are constrained by the current European Commission solution and time is against us. This is the most efficient and reusable way of working, in order to get the job done at the best standard possible, given the constraints we are working with.

This is basically where we are at in this point in time, I’ll update you in due course on how successful this strategy was. At a later date, I’ll talk through what went well, and whether we could have done anything differently with the benefit of hindsight.

If you’re still with me by this point, I want to finish by adding a little about my lifestyle and where I want it to get to. During this contract, my working pattern has typically been two days from home and three days in the office. When I’m in the office, I spend two nights at Village Hotel and use their gym. I bought a bicycle and took up mountain biking, I’ve probably been slacking over the last month or so, but I’ll be sure to get back on track. If you ever find yourself in the midlands, check out Cannock Chase, you won’t regret it. I’m still not as active as I’d like to be, I want to make more use of the Village Hotel facilities, they have an indoor and outdoor pool. I’d like to take up take up swimming, as a refreshing start to the day. I’ve always been a member of Pure Gym too; I want to use that more on the days that I’m working from home. I’m conscious that I made it sound like I’ve turned over a completely new leaf, I can assure you that’s not the case. Whilst I am healthier and would like to further improve my lifestyle, I’m still only twenty-seven and as I’ve proven again and again, nobody knows how to ‘turn up’ quite like I do.

How was my first year of contracting? It could only be summed up as one hell of a whirlwind. I have met some amazing people, made friends in every corner of the country, risen to the challenge on more than one occasion. I have learnt things about myself that I could have never thought possible, dug down deep when I felt like giving up and fought that little bit harder and came up on top. Now I stand before you as a man that knows what it takes to rise up against any challenge. That being said, there’s always room to learn and grow, in the words of Jadakiss, there’s one more mile to go.

Leave a comment

search previous next tag category expand menu location phone mail time cart zoom edit close