You have the client, the brief and the end goals. They want a new website that will modernise their existing site. What do you do next?
Assuming designs have been created and signed-off by the client, let’s look at the next stages of creating and managing a digital project.
Build specs
Once a design has been signed-off by management/ the client/ product team, the development team will need to work the project/product management team to create specifications for the work. This phase will require splitting the design into individual tasks. For example, estimating how long it will take to create the header, footer, home page carousel, and so forth.
Approve specs
Once the specs have been created into tasks, an estimated time will need to be assigned to each. Ideally, a best case and worst case scenario time should be assigned to each task. This is so that predictive forecasting can become more accurate and that the client can get a better understanding of when something can be delivered.
When creating a project, it can be a good rule of thumb to use the 8/80 method. 8-hours (1 day) to 80-hours (10 days) is the recommended minimum and maximum a project should take to complete.
Scope statement
The next stage of a digital web project is to let the client aware of the time and cost of the project. Again, assuming all is good, a scope statement can be created. A scope statement document allows all parties to see what is expected to be delivered.
A scope document should contain the following criteria:
Description
A brief description of the expected outcome.
Acceptance
The acceptance criteria will be a written statement of what will be accepted when the project has been completed. It should be specific to showcase what the user is expecting. A vague require acceptance criteria will say – a website that has x functionality. Whereas a more specific acceptance criteria will mention that the website needs to be mobile friendly, fast-loading, quick-loading animations with features matching the designs – for example.
Success
Define what success will look like. Again, be as specific as possible. Will success be that a new website will launch, with the ability to handle hundreds of orders or hits per day, that can successfully help their intended audience?
Deliverables
The list of deliverables needs to be addressed. Will the client just be getting a website? If so, how many pages and with what features?
Will SEO, training and support be provided?
Boundaries/ out of scope
As well as mentioning things that are in scope, we need to mention what is out of scope, just to make sure confusion is not created. You might add SEO to the deliverables, but not include search engine ads or off-page SEO.
Assumptions
What can you assume about the project?
You can assume that developers understand the requirements, and that the launch date will be a set date.
You can also assume that all code will be written to the best possible standard.
Product and project plan
After the scope statement, I like to create a project plan for the developers, so that they can refer to it at later stages in the project. This will of course tie-into the tickets.
Risks
Having a risk log or a RAID log is something that can be often overlooked. However, don’t be that project manager. Creating a log to manage risks, assumptions, issues and decisions is important so that you can correct mitigations and discuss with your team the correct cause of action.
Resources
Who’s in your team? Will anyone in the project likely be having time off during the time of the project, and if so has that risk been mitigated?
As well as human resources, what other resources do you have that needs to be included in the project? Laptop, 3D-printer?
Creating tasks
Once the scope and project goals are clear with the agreed timings and budget, you should convert to a project board. Popular project software tools include Trello, Jira, Monday, Azure Dev Ops and Asana.
Ideally you should split tasks into the correct sprints, and within those sprints create user stories. A use story is a useful summary for a group of tasks. You write a a user story by using the following format:
As a user I WANT… so that I CAN…
A user story is a note to add a question.
Milestones
It is good to create milestones in a project so that at certain dates we can check on the progress of a project. I like to milestones within tasks – usually at the half-way point as well. This helps keep track of progress and can determine if a developer needs extra assistance or time.
A project milestone can help see what is happening and if the project is on track. A milestone could finalising designs, completing the homepage or releasing the website onto a staging environment.
Communication plan
Quite simply, a communication plan should be created so that we know which stakeholders to contact, by which mentioned and at what points during the project cycle.
Kick-off meeting
A meeting with build team should take place before the project is started so that the developers understand the tasks, goals and the deadlines for the project. I like to record this meeting so that the developer has something to refer later down the line without the need to ask the same question multiple times.
Starting a digital web project doesn’t have to be difficult, however, it does take a lot thinking and managing. Because digital web projects are adaptative in nature, there is room for flexibility within a project, especially if a client wants to add something to the scope. However, be aware of scope creep and going over budget. And of course, mitigate all tasks appropriately.
