Website Project Management - Part 2

Part one introduced us to projects. In this next part of our website project management series we are going to get ready to begin the actual project plan. Before we do there are some things we need to sort out.

What you really need to know before you begin

It struck me the other day as I got more and more lost trying to find a clients offices how similar project management is to driving.

I had arranged to meet someone in a McDonalds car park who was going to guide me for the rest of the journey. I just needed to find this car park. Problem was due to fog on the motorway I was going to be ten minutes late so my boss called up this lady and told her to abandon me. Thanks boss. Now I only had a vague idea of where I was going.

Have a guess what I think the most important piece of information you need before you can seriously move forward. Go on, have a guess.

People in the past have been very confused when I tell them this but it works for me. I always start planning at the end and work back. In my opinion the most valuable piece of information at this stage in a project is knowing the *actual* destination. How will you know you are finished?

Start at the end

When I say the end, I mean the real end. everyone needs to agree when you are finished. In business I believe this is called an "exit strategy". When are you finished and what is the final deliverable?

Say you were an engineer who has been asked to build a bridge. Is the bridge finished when it stands up on its own? When traffic can move from one side to the other? When they can collect tolls? Is there an inspection? Do they have a warranty period? As you can see it is quite important for everyone to be in agreement where you are going in a project and how you will know you are at the destination.

In many projects this is the main purpose of a "scope".

Scoping

The scope at its most basic is a statement of what is "inside" and What is "outside" of the project. What is the teams responsibility.

Taking the goals and criteria from part 1 and defining in certain definitive terms what the project is about so that all are happily in agreement when it is finished that the project is in fact complete.

When you are building a website this would mean deciding if, for example, hosting and deploying to the host is part of the project. Is promotion and generating traffic your responsibility? If it is an ecommerce project who will be doing the logistics and handling payments? Are domain names and email configuration something you need to be concerned about.

In the 90's I worked for a company where the french parent company could not understand why we hosted client websites, they delivered servers to the customers door in a box and told them it was their problem. It is no good building something, handing it over and saying "good luck" if the customer is expecting the site to not only be visible on the web but found in their favourite search engine.

Work backwards

Like driving know where you are going then work backwards to work out how you are going to get there.

Just like in my disasterous drive, you need to look out for signposts. In project management parlance these are called "milestones". Breaking down a big project into smaller chunks makes the whole thing a lot less scary and a heck of a lot more manageable.

Some example website milestones

• Functional spec
• Sitemap
• Black and white line drawn screen layouts (aka "paper prototypes")
• Design in potoshop
• Cut up design into HTML and images
• Front end programming
• Backend programming
• Database
• CMS
• Testing
• UAT
• Deploy live

In between milestones, just like driving where you will steer, speed up, slow down, indicate, in a project you will need to make small adjustments as your plan is confronted by reality.

Milestones will not be enough to manage or estimate a project. Take each milestone and further break it down until you have a list of tasks, preferably no less than a half-day and ideally something that can be done by one person alone. The reason for this is your milestones and tasks should be "binary", that is either "complete" or "not complete". Other people judge completeness by percentages but in my experience this leads you to think things are progressing better than they are - there is always something that is 80% complete and that remaining 20% seems to take forever. 20% of the work can take 80% of the time.

This leads me to my next problem on my nightmare journey, because of my lack of prior planning I was winging it. Anyone who had done the same journey would have told me to look out for the bypass. I didn't know there was a bypass or how to get there so I just followed the signs that seemed to point me in the right direction. Unfortunately this route took me through rushhour traffic, roadworks, school run mums in SUVs and minivans, traffic lights and all manner of unfortunate delays.

Just the tiniest bit of thinking ahead would have alerted me to these risks. Sometimes in our haste to get started and just *** get on with it we cause ourselves all manner of problems. It can be more fun hacking it but in many cases we would be better off thinking things through first.

What risks might there be in your project?

Take some time out to think of things you might need to keep an eye out for, any potential problems that might be avoided. Build a safety net into the plan. An example might be not receiving content in time, or a problem at your ISP or a developer going sick. We will talk in more detail on this subject in the next part of the series. At this point just be aware that risk can completely change a project especially in terms of the work involved and therefore the amount of time it takes.

What goes into the project?

So somehow I managed to get to my destination, in the end being guided in like an amateur pilot in an airline disaster movie. In the end I missed my deadline by 8 minutes. This involved some last minute heroics (stupidity) on my part, driving 90mph in 40mph zones and I was worn out when I got there and still needed to deliver a full day of thrilling and informative training. Joy.

Recall last time we talked about the elements of a project you work with, time, budget and scope. As you will have worked out my "project" had a fixed, un-moveable deadline. In addition I had no way of reducing the amount of "work" without some pretty serious violations of the laws of nature. All I could do was "work harder". I guess by speeding and using my mobile phone I used more petrol and call time in a way increasing my budget spend :O)

In real projects you might also have a deadline, you might also have a fixed budget. The one part I find best to negotiate on is the scope. My preference is not to have a deadline, I would rather have a good quality deliverable, or rather deliver often small releases and bump functionality to other relases.

If you prioritise the deliverables you are better equipped to make these decisions. For each item decide if it

1. Is Essential
2. Not Essential But Adds significant Business Value
3. Not Essential But Nice To Have

Then estimate how long each will take plus associated risks. For example an item that you have never done before will have a higher risk therefore you should pad your estimate as you can not be accurate. While these will only be ballpark estimates at this stage you will be able to broadly time and cost your project and you will have some mechanism for deciding what should be dropped and what needs to be done. In rare cases you might even have enough information to know it's not worth continuing!

Summary of part 2

In this post we have looked at the difficult in-between bit, the deep breath before the hard work and how some time spent now could save you a good deal of trouble later. In the next and final part we will look at your actual project plan and discuss why a to-do list is a bad bad bad solution.