eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781780172040 |
|---|---|
| Publisher: | BCS, The Chartered Institute for IT |
| Publication date: | 09/15/2013 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 65 |
| File size: | 3 MB |
About the Author
Read an Excerpt
CHAPTER 1
KEEP IT SMALL
It is very tempting at the beginning of a project to include loads of things in scope and plan a 'big bang' deployment. However, this is rarely the best way to deliver change, especially in the IT arena. Where possible, packaging the change up into smaller, interim deliverables supported by full testing is a safer and more robust approach to implementation.
CREATING A SOCIAL WEATHER COMMUNITY FROM SCRATCH
Paul Craig took the role of Scrum Master on a project for the UK Meteorological Office. The Met Office provides weather data to NASA, the US Army and other places that cannot get the information from their own national met service. 'They are one of the global leaders in terms of a national meteorological service,' he says, 'but they were suffering from a bit of a PR challenge.' For all their skills, data and links to people in high places, they are still known as the organisation that gets the weather wrong. Everyone remembers the time when Michael Fish didn't predict the hurricane of 1987 (and if you don't, YouTube has the moment memorialised).
'There are thousands of amateur weather enthusiasts around the globe and every week someone would knock on the door in Exeter with 20 years of collected data and offer it,' Paul says. Until recently the Met Office couldn't do anything with it. Then a new IT Director arrived and wanted to start harnessing community weather recordings. He set the team a challenge: to see if new technology could be used to increase and improve the collection of weather data outside the Met Office. An Agile project team was put together and tasked with delivering something useful in the next 12 weeks.
'It was the first major Agile delivery project for the Met Office and this was completely new for them,' Paul explains. 'We had to force ourselves to slow down for the first 3 weeks. Within a month everyone got it.' Knowing that the team had to start small, they wrote down all the potential requirements and allocated each requirement 'requirements points'. 'The triple constraint still applies in Agile,' Paul says. The project had a fixed end date and a fixed cost so it was the scope that had to change. The project team held a two-day workshop to go through all the requirements. 'We said, "With your budget you can afford 300 requirements points. What do you want to do?"' he explains. This gave the team a straightforward way to put together a small but comprehensive scope, and meant they could easily justify why some things were in and some things were out.
That was just as well. The plan was to start small but to scrap the project completely if it didn't deliver anything that people wanted to use in three months. In the summer of 2011, WOW (Weather Observations Website) was launched. 'All the blockers you'd normally find on an IT project have been removed and it's very cost effective,' Paul explains. The cloud-based architecture using the Google App engine allows the development team to get on with what they are good at without having to worry about patch levels, servicing the environment and so on.
Despite the worry that short timescales and a limited project scope would mean that this small project wouldn't deliver anything of value, Paul says that the amateur weather community jumped on board almost immediately. 'The community is self-policing,' he said. 'They assess and review each others' data so they guarantee good quality.'
Using open source platforms also meant that the community could get involved with developing it. Someone wrote an add-on which enabled the site to display moving pictures, which was an improvement the project team hadn't thought of (or hadn't considered for the first iteration). 'It was a fledgling idea and it snowballed,' Paul says.
The WOW project created a brand new 'social weather' project from nothing. Since the launch, the site has received visits from 150 countries and receives one million weather reports a week from 3,000 to 4,000 amateur weather observers around the world – and they have done this all with no marketing.
Did it meet its objectives? WOW was never supposed to make money or to gather data to replace what the Met Office collects via the 'official' weather stations. The aim was good PR and Paul believes that this has been achieved. The amateur weather community likes it, the site has appeared on TV, and Google has produced a case study about it. For something that was a three-month experiment, WOW has taken the amateur weather community by storm.
The key to getting it right first time is keeping it small to begin with. Agile methods, with multiple iterations (or sprints) each adding more features to the product, lend themselves naturally to incremental build. You can also achieve this with waterfall methods if you keep to the principle of starting small.
When you plan the scope of your project, don't be tempted to include too many things. You can always have a phased approach where your first project delivery (and so your first scope statement) covers a small portion of what you would ideally like to do, then add subsequent phases to manage the rest of the roll-out.
There are very few projects that would not benefit from a pilot or proof of concept stage at the outset, so consider including one in your project scope. Rolling out a new system to a handful of users, asking them to test it rigorously and then making changes based on their feedback is a lot easier than deploying the system to everyone then managing the internal communications, bad publicity and general ill-feeling when you implement the fixes later. Your users will be asking themselves: 'Why would this latest update be any better?'
Piloting is also a way to contain costs. Identifying problems early gives you the chance to manage them when they are still small and can be corrected without significant cost.
While being able to test functionality and get early user feedback are normally the main reasons for a phased or incremental deployment, keeping it small also allows you to learn from the implementation process. The system might be great, but could you tweak the training material? That branch opening was a success, but when the bigger branch opens could you get more local press coverage? The new product is selling well to a trial group, but how can you act on customer feedback regarding service? Take the lessons from customer feedback about the end product and the feelings of your users with regard to the deployment process to inform and improve the next phase of the roll-out. Complaints are a gift: someone has given you the chance to tweak the product and get it right before you unleash it on your customers and to confirm that all the snags in the implementation plan are ironed out before you go for a huge launch. The benefit of starting small is that you have the opportunity to make things better for next time. Use it.
THE SIX STEPS OF PILOTING
1. Establish how a pilot could add value to the project by mitigating risk.
2. Get commitment from relevant stakeholders.
3. Define the evaluation criteria for the pilot: how will success be measured?
4. Produce a project plan and other project management deliverables.
5. Deliver the pilot: run it for a predetermined length of time.
6. Evaluate the success based upon the criteria established in step 3.24
Putting a pilot or proof of concept stage in the scope of your project and/or planning an incremental approach to delivering functionality will allow you to fully test both the deliverables and the implementation approach, so that you do not lose the support of your project customers by delivering something that is not fit for purpose.
CHAPTER 2KNOW WHERE YOU FIT
Your work on a project fits into a larger strategic picture for the organisation as a whole, or at least it should. Everything you do on your project should be aimed at helping the company achieve its strategic objectives, and it should be clear to you how you are contributing to this strategy.
LINKING EVERYTHING TOGETHER
Antony Tinker, Sales and Marketing Director for Kent-based change consultancy Innovative Edge, knows a bit about how to ensure that projects are linked to programmes and upwards to business strategy. After all, it's what his company does.
'As we are all about aligning people and strategy a big part of our exploration phase when we work with new clients is to understand their business strategy,' he says. 'If their strategy is clear and understood we will link everything we do to it, or parts of it. If it is ambiguous, not understood or not believed then we will propose a solution to address this.'
The exploration phase is where Antony and his team sit with the client and establish what project benefits they want to see. They spend a lot of time carrying out one-to-one interviews, exploring the commercial background and the company culture, asking about the rational and emotional issues and trying to get to the bottom of the benefits the company wants to realise. 'By identifying their pain points and having a discussion they can begin to articulate how life would be different (better!) without those pain points,' he explains.
Once the benefits have been established, they can be delivered through a project, or series of projects. However, each project still needs to link to a programme of work and the overall corporate strategy. 'When we present our proposal back to the client we cover off the features and the benefits of carrying out our proposed project plan. As we design every intervention bespoke for each client this is relatively easy to convey, and very authentic,' he says. 'Authenticity is vital. If you say it's about them then make sure it is. They'll see through fake words and actions very quickly.'
He is also prepared for things to change, as they often do on projects. 'You should be open minded – as should the client – to evolve your plans as you work through the project, as long as you remain dedicated to genuinely helping them achieve their objectives and goals,' he says. 'Inherently therefore everything is linked, no matter what changes, and we can demonstrate this.'
Antony believes that linking benefits, projects, programmes and corporate strategy results in better alignment between individuals and the company goals, happier teams and a positive impact on financial results.
'If you don't know how your project links to business strategy, ask more in breadth and depth questions,' he recommends. 'Make it your client's agenda and not your own. When you ask a question listen to the answer rather than thinking of your next question.'
The OGC P3O standard defines a portfolio like this: 'the totality of an organisation's investment (or segment thereof) in the changes required to achieve its strategic objectives'.
The OGC P3O standard defines a programme like this: 'a temporary, flexible organisation created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation's strategic benefits'.
Have you ever asked yourself why you are working on something? If not, then now is the time to start asking. Often project managers are told what projects to work on with very little background or context. As a result, it can be hard to energise a team towards a common objective when you can't see how your work contributes to the bigger picture.
Ideally, business strategy should be manifested in the form of portfolios, which are delivered via programmes and projects. Therefore it should be a straightforward exercise to map your project through a programme and portfolio and back to strategy, as you can see in Figure 2.1.
Durbin and Doerscher, in their book Taming Change with Portfolio Management, describe different types of portfolios and explain the links between project portfolios and programmes/projects like this:
Execution portfolios are used to manage the tactical details of how projects, services, and the activities within them are planned and executed as well as how resources are assigned and managed. Execution portfolios give managers the opportunity to organise and view data from common information sources based on their specific decision rights and needs. Managers can focus on the information and issues that are meaningful to them and coordinate their activities with other managers. Because of the relationships defined by the information structures, they can also clearly see how their actions relate to the bigger picture.
However, many smaller companies (and even some large ones) don't work on a portfolio basis and use programmes and projects directly to deliver strategic objectives. Even if your company doesn't have programmes of work, you should still be able to tie your project back to something bigger than the output that you have been asked to deliver. If you are struggling, see if your project's objectives align with your sponsor's personal objectives for the year.
If you can't see any clear link between what your project is supposed to do and how it will help the organisation move forward, maybe it's time to close the project down. An example of this would be where the business strategy has changed since the project's inception and the project will no longer deliver a valuable output. This could happen if there is a change of senior management or a corporate refocusing initiative. Suggest to your project sponsor that if your project is no longer going to achieve anything that supports the overall business strategy that it should be stopped. The resources could most likely to be put to better use working on something that will move the organisation forward.
You and your team will feel as if your work is more worthwhile if you understand how it contributes to the overall aims of the company, and it makes better business sense to ensure that your project is aligned to strategy – so find out!
CHAPTER 3WORK OUT HOW TO MANAGE CHANGES
Change is an inevitable part of projects. The purpose of a project is to change something – otherwise we wouldn't do projects. There are two types of changes:
• changes that come about as a result of the project i.e. the deliverables of your project, and;
• changes within the project e.g. as a result of factors like new requirements, upgraded technology or external pressures such as new laws or modifications to regulatory frameworks, or a sponsor who changes the priorities.
The impact of the first type of change is hopefully the subject of your project and has been carefully planned with a communications and implementation strategy. It is the second type of change with which we are concerned here: how to manage changes that affect your project objective in some way. Changes will happen, so working out in advance how best to handle these will make the whole process easier when one comes along.
KEEPING IT UNDER CONTROL
Process-driven industries rely on accurate monitoring and careful management of changes, as Leo Dijkhuizen, knows well. He has spent ten years in a chemical and pharmaceutical environment in the Netherlands, where strict change control procedures are a necessary part of his role as a project manager specialising in SAP software implementations. Working on projects with budgets that stretch into millions of dollars and time frames of several years he has found it absolutely critical to manage changes in a controlled way.
Leo explains the change control process of a project to define and implement a global SAP system: 'Each change had to be justified with a business case,' he says. 'The steering committee reviewed and approved – or rejected – each business change.' The system was being rolled out across six European countries and the US, with the aim of globalising the company's supply chain and lowering inventory costs.
The project took three and a half years, and with a budget of $32 million it would have been easy for small changes to mount up over time and push the scope and budget way over what had been anticipated. 'The customer required a tight control over changes, so it was not difficult to implement a change control process,' Leo says. Having a global, centralised change control process helped to achieve a smooth roll-out across the seven countries. The steering committee signed off each change and was sure they individually each understood the implications.
Leo's advice is to find someone in the project structure who can act as a sponsor for the change process. 'Make sure this person operates at the right level in the organisation. If you cannot find someone who meets that description, ask the steering group what their policy is regarding changes and develop a process to manage each change around that.'
Change control or change management is the process of managing unplanned but desired influences on the project. It is important because any change will:
• need to be analysed for its impact on project objectives;
• need to be analysed for its impact on project scope;
• modify your existing plans, and;
• need to be recorded properly for a complete audit trail.
(Continues…)
Excerpted from "Managing Project Scope"
by .
Copyright © 2013 Elizabeth Harrin.
Excerpted by permission of BCS The Chartered Institute for IT.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
AuthorGlossary
Introduction
Keep it small
Know where you fit
Work out how to manage changes
Include quality planning in scope
Work out how to track benefits
Eliminate ambiguity
Use version control
Put a post-project review in scope
Identify risks upfront
Manage risks
Manage issues
Document assumptions
Involve users in scope definition
Communicate and document changes
Plan for handover into production
Actively manage requirements
Index