This blog post was created as a result of viewing a tutorial on Preventing Scope Creep by Terri Wagner.
When starting any type of project, it is important to understand the goals and outcomes expected of the client whilst trying to gain maximum understanding of what would benefit the end user most.
The difficulty with developing a lot of the projects we develop is that they more often than not, are on going processes. Such as, we start with a problem, and we try to implement a solution. And its not every time that 100% of the projects features are laid out until initial prototyping and user testing has taken place. Therefore project scope creep is always a potential issue that needs to be kept in check.
For a commercial team this is probably easier to prevent. But when working as part of a larger organisation such as a University it becomes more tricky. This is because as well as new projects that arise, there are old and on going projects that require support, enhancements and fixes to maintain them. We must carefully balance our workload as a team to at least provide consistent and effective support for our academic staff and students in particular, but also to allow us the opportunity to innovate into new grounds using new technologies that aid learning. An example for us is the support we provide our staff and students for the DLE, ePortfolios, TBL, SIG’s, staff development, research and so on, prevents us from going all out on a project. Sometimes a critical issue may arise meaning existing projects must be immediately put on hold, immediately leading to issues with deadlines etc. What I learnt from this Lynda course more than anything is that documenting and communication is key to successful development of new resources.
Where scope creep is referred as: added features and requests from the client or manager without extending budget or schedule.
Gold plating is a new term to me: developer added features unknown to client and or managers.
I’ll confess right here… I’m guilty of gold plating, definitely! There are reasons why but I’m not going to into this detail in a blog post.
Whilst I’m not a manager as such, I am trusted to manage some of my projects from start to finish so scope creep is still something I need to be careful of and not just gold plating.
One of the challenges faced documenting a project specification is you need to accurately breakdown a list of tasks, sub tasks and attach each to its own schedule and deadline to meet the end goal. This is known as a Work Breakdown Structure (WBS). And the challenge is with some projects, especially those that are more innovative, bringing new and emerging technologies together means there’s a lot of uncertainty and therefore difficult to give detailed timescales. The Lynda course gives a lot of breakdowns for what a mature organisation would utilise for these projects and they all start with consistent documentation templates. Consistency between projects allows great understanding of who does what and when as well as to provide communications to the client about progress, resolving bottlenecks and spotting scope creep early on.
The course talks about two types of projects:
- Plan driven – fully defined project before starting
- Change driven – expected small iterations throughout
Documentation
We utilise various methods to document our work. And depending on who is going to look at a particular documentation we use different services. Reason for this is inner team documentation is likely to pretty technical whereas for staff and students it will be written differently in a way that talks about work in a more tangible way.
With the types of new projects we work on with academics, there is no exchange of money as such and the timeframes usually flexible as we rely on them for content and they rely on us to enhance and develop. Therefore the change driven approach is usually used. However some initial documentation is important to lay the framework of expected deliverables. Important requirements include:
- Value to the end users.
- Risk involved, i.e. waste of time reinventing the wheel when there’s already something that meets 80% of what they want.
- Difficulty to create. More innovative projects usually tick this box but with experience this will be less of an issue.
- Chance of success. That it actually benefits our students or helps our staff in some way and gets used.
- Urgency. Such as to replace a broken, no longer supported 3rd partly application or system.
Communication
It is recommended to have a communications management plan (CMP) to stick to as your progress through a project. This helps prevent scope creep and make sure the correct features are being implemented as expected. A CMP can include:
- Stakeholder needs
- Organisational needs
- Content, detail, frequency
- Time for distribution
- Person responsible
- Urgency
- Escalation procedures
Development
When working as a plan driven approach, its more straightforward providing all the right documentation is in place. When working in a change driven way it can be challenging to keep a project on track and avoid scope creep. The recommended solution to this approach is to:
- Prototype – create early prototype to show. This will help feed further ideas to nail down a more specific feature documentation.
- Multiple iterations – regular communication and show and tell sessions will help make sure you are on track and not going completely off track.
- Agile techniques – We often use the Kanban method as many projects are developed by a single developer. But for larger team projects we us the Scrum method.
Conclusion
This Lynda course reiterated a lot around the importance of communication and documentations to prevent scope creep. Whilst I feel communication is pretty good with everyone we work with. Documentation is a key factor that could be improved upon. The course talked a lot about organisation maturity and that simply comes with experience. Creating processes and templates, improving them and their efficiency will put you on the right path to avoiding scope creep (and gold plating!) in future projects. We already do a lot of what was highlighted in the course. But bringing it all together consistently is a key factor of success. The course talks about ‘scope fuzziness’ which is a term used to represent overly vague understanding of the work to be done. More often than not, our clients know what they want but do not know the features required to realise the goal. This is where we need to provide our knowledge and experience to provide a clear explanation through documentation of what is required, why and how long because … .
There’s a lot to learn, one video talked about a SMART technique: Specific, Measurable, Attainable, Realistic, Time bound. By implementing all of the above and this technique and agile techniques whilst maintaining documentation and communication, project scope creep should be kept to a minimum and production will be at its maximum.