The project management survival guide – it’s all about planning!
Written by Grace Davies on 7th June, 2017
Here at stickee, we’re experts in every stage of a web design project. Our creative team is armed with years of experience to provide our clients with the perfect digital product, and know that one of the most important parts of any project is the planning phase.
Every stakeholder in a project needs to be working toward the same end goal. Part of the Project Manager’s job is to make sure everyone knows their role in the process, and clearly setting out a plan for the people involved to follow. Think of planning a project like the foundations of a house. Without it, the entire thing will collapse and you’ll be left with a useless pile of rubble. Or a useless pile of code.
Over half of technology projects fail due to poor planning and management. Here’s how we make sure this doesn’t happen to our clients.
When planning an IT project, we usually select one of two methods (there are others, but most clients know these):
Waterfall method is a more traditional way of running a project: we start with a general idea for what we’re trying to achieve (like building a website) before planning the different stages of the build and design process and completing them in the designated order; Analyse & Plan, Design, Build, Test, Deliver It is a sequential process that flows steadily through the phases- like a waterfall!
Agile method is, well, agile – it’s a more non-linear way of building a website. Instead of waiting until the end to perform testing, we break up the scope into smaller pieces and plan,build & test each stage of the process as we go along. That way, we’re able to analyse what’s working and what isn’t quickly, and correct mistakes straight away before moving onto the next phase. This methodology is more iterative, so you’re constantly going through the phases.
We don’t consider either of these methods to be better than the other – everything depends on our client’s needs and the type of project. Either way, picking a methodology and sticking to it creates a solid base framework around which to create the project, so everyone can follow.
Stakeholders and Objectives/Goals
A project should meet the goals and objectives of the stakeholders. Everyone associated with or impacted by the project is a stakeholder, and it’s important that we identify them early on and understand their needs, but also identify their responsibilities. By establishing the stakeholders, their needs and how they will contribute, we can be sure that the right information can be drawn out within the Planning stage but to also be sure that we know who signs off what when the end product is delivered to them. Stakeholders in a web design project might be:
- Our client and their team
- Our project manager
- Our web design and development team
- The website’s end users
Once we’ve established who the stakeholders are, we need to find out what they need; both from an end goal perspective right down to the granular detail. Every client is different, so it’s important that the whole team knows what they are working towards – that’s why we ask them to share their objectives with us. After deliberating with the client, the project manager can write down a list of requirements and organise them by priority level.
The list of requirements allows us to create a set of SMART goals for the project and organise our resources depending on those goals. From then, we can establish a structured schedule and decide on the best way to carry out the project. These objectives and requirements are also used to create a Specification which we’ll come back to later on.
Following on from the above (requirements, objectives and stakeholder management), setting expectations is a key part of the Planning process. Agreeing on a budget, schedule and (realistic) deadlines is also essential and needs to be discussed with the client – it’s all part of managing expectations. While we always do our best to deliver the finished product on time, within budgets, and exactly the way the client wants it, projects can be unpredictable and changes may be requested.
A thing we like to establish with our clients is a constraints matrix as a way to find out which of scope, time and cost is the most important to them. We then pick a rating for each of them, out of fixed, some movement, and flexible. So if our client has a very tight budget, but are willing for the project to take longer than they expected in order to stay within the budget, a constraints matrix will look something like this:
It’s important to have the discussion before the project starts and agree on some flexibility so there’s no surprises for us or our client halfway through the website build. Ultimately, though, it is the client’s project, and they get the final say. The project manager can only make them aware of potential risks (lack of resources, potential missed deadlines, etc) so they can make the right decision.
One huge part of managing expectations is getting everything in writing. That’s why we always draft a requirements specifications document (this can take different forms, based on what methodology is chosen), detailing exactly what the end product is going to do and what it won’t do. This is absolutely key to any project’s success as it sets the parameters for quality, right from the offset. That way, if any disputes arise (thankfully, this is rare), both us and the client can refer to the document to see what was agreed upon at the beginning of the planning process.
Things we usually include are:
- Granular details of the expected finished product
- Both functional and technical requirements
- Any accessibility/responsive requirements
- Details of the schedule and method
- Details of the resources and budget
- What obstacles might we encounter? (This can go in a separate risk management document)
Any changes to the plan or product (changes in budget, scope, or deadlines) are recorded in the document.
The last part of planning a website build or redesign, and one of the most important, is creating the wireframe. We see it as a blueprint (like you would create for a house), allowing us and the client to visualise what the end product will look like. A lot of people are visual people and so this part of the project is really insightful and often, the requirements can change at this point…
Our designers will draw up a rough sketch of what the finished website is expected to look like – but without too much detail. We’ll show the client where specific buttons will be, what the navigation will look like, and more, and check with them that it matches their expectations. In bigger projects, we can also create a ‘clickable’ wireframe, which mimics some actions of what the end product will do. This interaction is invaluable when assessing if it’s a success with the client or end user.
We often ask for the client to share these with the end user (if it isn’t them) so get their input to really make sure the end product will be fit for purpose and to ensure we’ve interpreted their needs correctly. Once they agree, it’s time to get the project started!
Get in touch today if you’d like to discuss a project – our creative team will be delighted to help.