Working here for over four years now has given me great opportunities to work within the different team structures throughout the company on a number of very different high profile projects. This has provided me with a foundation to manage projects effectively with the knowledge and experience required to make sure resources run smoothly.
Recently, I attended a four-day AGILE project management course. With AGILE seemingly becoming more popular, the course gave a great insight into what the AGILE approach is, how it differs from traditional project management and how companies can use it to their advantage. Here is a brief overview of what I learnt and how I will go about applying it to how I work at Edit Agency…
What is AGILE Project Management and how does it differ to the Traditional Approach?
So, the tricky bit – describing to someone who may know nothing about project management what AGILE is… basically, in the traditional approach to project management, the features of the project are fixed, meaning time, cost and too often quality are subject to change in order to keep the project on track.
So for example, in a typical website build – the features such as the homepage, product pages and checkout processes are requirements. Sometimes if poorly managed however, in order to design, write necessary content and code the site; more time or budget may be needed to complete them as project slippage occurs.
Alternatively, quality may suffer when deadlines or budgets cannot be altered – so for example, testing the website for bugs at the end of a project may not be done in order to hit those targets. This can be disastrous for the website in question, whilst also harming the reputation of the companies involved.
The below diagram illustrates the Traditional and AGILE project variables:
The AGILE method meanwhile fixes time, cost and quality of a project, while the features to be delivered act as the variable within a given project timeframe. So how do you determine which features are included and which are left out? The answer is MoSCoW.
MoSCoW Prioritisation
No, not that one! MoSCoW is a technique used to reach an agreement with all parties involved on the importance they place on the delivery of each requirement (in my example above, this could include the pages of the website to be built for instance).
MoSCoW is an acronym to categorise the following:
- Must have requirements are critical to a project’s success. If even one MUST HAVE is not included, the project would be considered a failure. Sticking with the website theme here – things like the homepage, product pages and the checkout process may be included in this section. Without these essentials, there would be little functionality for visitors to use the website, making it of no value.
- Should have requirements represent a high-priority item that should be included in the solution if possible. A mobile-ready build would be a good example, as more and more of us are using tablets and mobile phones these days to purchase products, so it would make sense that a website should have this facility.
- Could have requirements are less critical and often seen as nice to have items. Blogs and social media functionality could be included here – they are included on most major website brands these days, but are not essential for the website to function correctly.
- Won’t haves are the least-critical and (as the name suggests) will not be covered in the project timeframe. They are essentially your project contingency, you don’t plan to have elements not included, but these are the features considered safe to lose in the initial project phase without compromising the core business case of why you are building the site in the first place. Perhaps creating things like a Facebook or Google+ page will not be part of the scope of the project.
AGILE recommends a project should consist of no more than 60% MUST HAVE requirements with approximately 40% distributed between the SHOULD HAVES and COULD HAVES. As the features of the project are the only variable that can change in an AGILE project, anything higher than 60% MUST HAVES poses a risk to its success.
Why the AGILE method might not work for a full website project…
Obviously the best case scenario is that 100% of the project, all MUST, SHOULD and COULD HAVE requirements are completed, however it needs to be agreed with the client up-front that there is a potential outcome that due to time, cost and quality being fixed, only 60% of the project is built with the resources available during the period the project is undertaken.
Based on this, it is highly unlikely that a client would sign-off a website build based solely on this approach to be honest, but this is why it is essential that the business case is built on the MUST HAVES rather than the project as a whole.
That’s not to say there aren’t aspects of AGILE that we cannot use however. The above details briefly the fundamentals, but there are many aspects of AGILE which we can apply to a project and use in conjunction with other project management practices.
Indeed, Branded3 effectively utilises parts of the AGILE approach in its day-to-day management of projects currently, alongside a more traditional method to get a balance that’s just right.
The best of both worlds
Communication and collaboration are huge principles relating to the AGILE approach throughout all levels of a project, from the customer all the way through our account management structure, to the designers and developers actually building the website and making it look awesome.
Delivering incremental parts of the product combined with risk management and informal face-to-face meetings with our clients ensure that a project can be signed-off step-by-step.
Collaborative planning, wire-framing before proceeding to full designs (in AGILE terms this would be called ‘modelling’) and content creation can all be reviewed and accepted prior to progressing with coding the site and joint testing.
This way, we are able to implement any feedback during the project and are safe in the knowledge that we are delivering what the customer expects/requires rather than waiting until the end when perhaps it may be too late in the project to alter or change anything.
Final thoughts
Overall, as I’m sure you can appreciate from my rather extensive post, I found the training course really interesting and engaging – felt like I learnt a lot and cannot wait to apply many aspects of the methodologies to our projects going forwards.
As Project Managers, there is ever increasing pressure to deliver working solutions to business problems and opportunities in shorter timescales without compromising quality. As such, it is our responsibility to move with the times and adapt our approaches to different methodologies where applicable.