Project Management
Project Management Information
Some notes on Project Management, by Pete Sipple
Every now and again, I’m asked for guidance on project management. Here are some thoughts, based on my experiences.
Project Management and Me
I formally became a project manager in 2004, but it seems that I’d been a project manager for many years before then, without really recognising the term. When working for Essex Radio in the mid-to-late 1990s, I was actively involved on three big projects, the Essex FM website, installing the playout systems for radio stations in Southend, and the Year 2000 compliance project for the Daily Mail group of radio stations.
My first formal project Management role was with a company called Mobile Innovation, based in Central London, after transitioning from roles in software specification, and new business development.
Good Project Management
Each Project Manager is different, each project is different, and each senior manager’s expectation of Project Management is different. Here are the top five lessons I picked up along the way:
- Project Management is 30% diplomacy, 20% common sense, 20% task management, 20% good admin, and 10% backside-covering
- Protect your team. In any project, there can be a number of warring tribes: senior managers, customers, third-party partners, internal stakeholders and in-house talent (designers / developers / QA). Your team are the most valuable, and it’s your job to protect them
- The PM is there to be blamed. This is for everything from forgetting to send off a status report, to the loss of an account or the failure of the project. Even if you’ve done all you can, you’re there to be the scapegoat
- Admit when you’re wrong. The team will respect you, the management will blame you anyway, and honesty is the best policy
- Gantt charts are not the answer. If a manager asks for Gantt charts, be warned. Reliance on Gantt charts can be a recipe for disaster – they’re handy for milestones, but a good PM can track milestones and progress without the need for a Gantt chart – a task list and milestones summary can be far more effective, easier to maintain, and more easy to share and understand
What you need to know
Again, based on my experiences, here’s what you need to know to run a successful project:
- What’s expected – From the customer and Internal stakeholders. Before starting the planning, extract the key dates and deliverables. Question these dates. "I need a beta by next month" isn’t enough. Ask the questions: "does that include testing?", "who will be using it?", and "what do you mean by beta?" (as definitions vary)
- Planning – Next step is to sit down with your team leader / senior developer and scope out the project: What are the real requirements? What’s hard? What’s needed? Does the team have the right skills? The aim is to get together a good solid list of all of the tasks. Teasing out a task list from the team can be hard, but is vital, and empowers the team to take responsibility for delivery
- Dependencies – What’s needed, from whom, and when. A surprising amount of dependencies are required from the customer, and this list should be gathered by the PM early, and presented (with dates) to the customer. Delays on getting these should be highlighted, as late delivery is one of the most common reasons for a missed milestone
Project Management Methodologies
There are essentially two main types of approaches used for planning and executing a project:
- Waterfall – Requires a solid specification and a committed team with the right skills. Phase-based delivery – Requirements > Planning > Specification > Design > Development > Testing > Release. It’s a rigid framework, but makes for easier planning and clear deliverables. Gives the option for reviews at each phase.
- Agile – There are many variants of this model. I’ve had most success with a variant of Agile, Extreme and Scrum. Basically, agree a deliverable with your team and the customer for the short-term. "Spec in a week", "Alpha of features x, y and x in a fortnight", etc. Work with your team (with daily meetings if things are slipping) to hit the date. One of the best models I’ve seen was developed by a chap called Steven Webster from Interation:two in Scotland. It involved creating an "anthology" of "stories (i.e. delivery milestones). Each story was based in two-week sprints, with the deliverables agreed at the start of the sprint, with the acceptance criteria defined by the customer. Velocity of the sprint was based on the time-to-deliver of the previous story. Hard to explain in a paragraph, but essentially, agree some short-term goals and get the customer’s early buy-in. They feel more involved, see results quicker, and can see the result of changes much faster
Ultimately, which type you pick depends on the customer. If you have a free hand, the key is to set milestones early, and keep the customer informed of progress towards the next milestone.
The better PMs appear to develop their own, and find the right way of communicating it to the appropriate parties. In my last role, I developed a kind of rapid, extremely-agile waterfall model that kept a demanding customer, and overworked team and internal sponsors happy(ish)
Project Management Information
In the UK, "Prince 2" is the agreed and accepted standard – Larger organisations may mandate Prince 2 as a requirement for Project Managers. You can find out more about Prince 2 at www.prince2.com
If you’re looking for a good book on the subject of Project Management for the software industry, you might want to consider getting a copy of the Software Project Survival Guide
Software Project Survival Guide Book Cover
Book Blurb: Equip yourself with SOFTWARE PROJECT SURVIVAL GUIDE. It’s for everyone with a stake in the outcome of a development project – and especially for those without formal software project management training. That includes top managers, executives, clients, investors, end-user representatives, project managers, and technical leads.
Here you’ll find guidance from the acclaimed author of the classics CODE COMPLETE and RAPID DEVELOPMENT. Steve McConnell draws on solid research and a career’s worth of hard-won experience to map the surest path to your goal–what he calls "one specific approach to software development that works pretty well most of the time for most projects." Nineteen chapters in four sections cover the concepts and strategies you need for mastering the development process, including planning, design, management, quality assurance, testing, and archiving.
Available from amazon.co.uk
Got a question?
Got a question, or a suggestion for what can be added to this page, please get in touch.
