It’s all Greenfield – managing projects right from inception!

I’ve recently had opportunity to apply an entirely unesscary but wanted amount of rigour to a component of my Webshop project and my reasoning to do so was it was a great opportunity to run through and simulate what a ‘green field’ project at the client site could look like. And then document those results. You can sometimes have ‘too much’ planning & not enough doing, especially with large organisations & the secret is to find the balance, that sweet spot that sits just so, to ensure you give the business protection, but also get things done!

What’s a green field project?

This is where you have the perfect opportunity to start entirely afresh. It’s the holy grail, no ones been involved previously, there’s no back story or history so is ideal to test process when this golden opportunity arises.

The Project

In itself it’s a small subset of work needed to be completed to a deadline to allow the completion of the webshop project proper. It involves transferring all the customers from our various other websites to our primary new webshop, and then closing those old websites down. It has just enough amount of juicy risk and technical complexity to warrant running it as a small project and testing process subsequently.

What did I do first.

The first thing I did was clearly gather the requirements ensuring underneath all the industry terms, inferred knowledge people expect everyone to have, the three letter acronyms we love, everything was clearly explained –  to summarise what we’re trying to achieve in a language my mum would understand. I then validated this with the key stakeholder & Sponsor, and then used this understanding to populate an IT Project Charter (a key component that dept. needs, when sizing up new work that involves them as a team).

Next up was the plan itself. Working back from the required delivery date, I tasked out chronologically key task areas to achieve the goal knowing that I’d need to go back and ‘flesh the bones out’ by working with the various subject matter experts. I did this over the course of a day to produce a backbone plan with some key dates & dependencies. (see my blog post how to use Microsoft Project here)

Documentation, Documentation, Documentation

I then thought about all the components needed to report on the project, and all the parts which make up a project & created those, using the guidelines set up and outlined by our PMO team and something I was actively involved in authoring from scratch. So I made sure we had;

• A Project RACI (For roles responsibilities and who needs to know what)
• A project RAID (where our template here captures also decisions)
• A Microsoft Project File
• A folder to capture all the actual project work
• An email archive folder (this is best practice if you ever do project management in a sector such as Law or Medicine, all the emails relevant to the project are stored in a folder outside of Outlook for filing purposes)
• A meeting minute folder
• A project reporting folder to contain things such as PSR’s (Project Status Reports) week on week.

I’m pretty happy with the structure for any type of project really. Working my way back from asking myself, ‘what would I need to demonstrate if my project was audited’ I simply ensured all those (currently empty) components were there. It also acted as a guideline for me, outlining the work I needed to do. As far as I’m concerned, we should run every project this way and I certainly run every project this way client to client.

Giving people the tools.

The next thing I did was (as I was responsible for this too) was consider the work which would be conducted on the project. This summarised as;

• Software development (so that meant code environment, repo, back up and agile tool management)
• Testing (so that meant involvement with IT to ensure a suitable UAT, Pre-Prod and Production environment were set up)
• Domain migration (so that meant ensuring that all the registrar’s involved had their contact details documenting and there was an accessible nominated contact who could speak to the registrar’s and handle record changes & domain switch off’s etc)

I arranged the documentation of the registrars in question, to ensure we were able to talk about the respective domains quickly. I then audited those domains prior to handing the information over to the tech guys so they had everything they needed, what records were present, when the domains wanted switching off, who the provider was (etc etc) that way, it made their job easy.

I also set up a Trello board to help with agile progress management, it was light weight and an easy way to integrate into the landscape everyone was familiar with. Although now, I’m using Monday.com more & more and I’ll be doing a little video on the benefits of that in an organisation, very soon.

I set up a Slack Channel dedicated to this project, and invited the team. A Confluence board with links to all the project files, the JIRA instance we used for testing & support & distributed these links in a small presentation which I then circulated.

Go Go Go Meeting

The final thing I did after putting all this together was hold a sub project launch meeting. This allowed everyone to ask questions, I could ensure everyone had consumed all the project documentation and clearly understand what we were trying to do and had opportunity at this point to re-interrogate the project plan and query any dates. From this point forward, I was confident everyone had been included and knew what they were doing. At that point forward it was baton to them, and for them to run with.

In Summary

When committing to a greenfield project, there’s a couple of solid questions one can ask & are pretty good guidelines for when deciding on how to proceed;

Traction – is there enough requirement generally for the path we’re proceeding down to be valid?

So in this instance, is the need to switch off the old webshops worthwhile or are we creating work for the sake of it? In this instance there’s a financial impact to keeping the old websites online so we know we need to proceed with this piece of work.

Credibility – is what we are doing going to make sense?

Sometimes it’s easy to get lost in doing something, without remembering the last time you stepped back, stopped and said ‘why are we doing this again!?’ This came up in this project with redirects. We’d applied a strategy for low-level (below the TLD) redirects meaning we had a technical challenge to find somewhere to host host-files to do inline DNS repointing on the fly. With hindsight, the commercial benefit of those re-directs being in place were offset against how technically challenging the task was, and how much time had been spent achieving it.

There’s a great PDF here which outlines some key things to consider & a checklist for when you’re migrating sites. Some other useful information;

Debunking the anticipated traffic-drop myth.

Anyone who’s ever been involved with site migrations has probably heard if you mess it up, you’ll suffer revenue loss because of it. Even though this assertion holds some truths for very specific cases it’s certainly not gospel. You do however need to plan properly and execute perfectly.

In fact, I’ll let Moz’s blog take it from here, it really is excellent & continues this conversation. Enjoy