Building software without a project schedule is like driving a car without a seat belt; it can be done, but that doesn’t mean it’s a good idea. Before I continue, I must say that this article is not about why you should have a project timeline. If you need that kind of convincing, I suggest an excellent article from joel spolsky I call Painless project schedules. In fact, the project programming style I use is derived from his method.
What I would like to talk about is how Google spreadsheets can be a real treasure when it comes to making your project schedules. Like many tales, this one begins with a cause that must be defended. Not long ago, I worked in a company with three programmers. It was my job to make sure projects were delivered on time and to spec. Resources in this company were very scarce. This meant that any time savings he could get by simplifying a process, he would.
In the past, you’ve used Microsoft Project or Microsoft Excel for programming. Putting my project schedules into Google Spreadsheets offered a number of benefits. On the one hand, the schedule could be accessed from anywhere and at any time (home, office, mobile, etc.). Another advantage was that multiple developers could edit their relevant areas without any sharing problem. Also gone were concerns about backups and where on the company server the file should reside.
If you look at the project schedule structure I use, you might think “it’s so simplistic, surely that’s not enough to cover a complex project.” But really, what more do you need? Write down what the task is, an estimate of how long it will take, who should do it, and how much has been done.
Okay, you got me: this style of project schedule has two major flaws. To begin with, it is difficult to determine delivery dates, another problem is that it is difficult to mark a different milestone. But where this style or project schedule shines is in task management, you won’t miss a thing, and as the saying goes “the devil is in the details”. It’s a great way to distribute tasks to team members. It also provides a very good overview of where you are at any given time within a project.
Personally, I tend to create my project schedules with only five phases (you can have more if you want). I found that all tasks fit into one of these categories: wireframes/mockups, coding, project management, QA, auxiliary tasks. Ancillary tasks are the “catch-all” for tasks that don’t fit neatly into any of the other categories.
I also like to create a ‘summary and charts’ page, but this is a blast. I find it helpful when my boss asks me “how’s the Widgets project going?” I can answer “Overall, it’s 92% done, we’re on the right track.” It is also helpful to know how many hours have been allocated to different team members. One of the reasons I do this is because I have a bad habit of taking on too many technical tasks that really should go to the production team (what can I say, I used to be a programmer).
Having a project calendar is great, but the unfortunate reality is that most people don’t care. In my experience, senior management is usually not that interested in the details of the schedule, but they do appreciate its existence. They will be more interested in milestones and delivery dates.
The other hurdle is getting programmers to use the schedule. Most of the time I’ve found that schedulers aren’t very interested in being directly involved in schedule maintenance, but you have to bring them into the fold. Programmers are much more interested in hacking code, which is a good thing: it’s what they love to do and what they’re there to do. So how do you get your technical staff involved in the project schedule? Basic people management skills really. People will be much more inclined to do something if you ask do it instead of organize to do so, and people are more inclined to do something if they are given some choice about it. To a lesser extent, that often vague concept of ‘ownership’ comes into play here.
What I often say to the programmers I work with goes something like this; “Tony, when you have time, you can go to the project schedule and update your areas. Also, for the life of this project, I need you to come in at least once a week to update your areas.”
Over the years, I have found that this approach works very well for a number of reasons; there is ‘choice’ there; Saying “when you have time” and “at least once a week” leaves a breathing space for people to figure out. People are always happy when they have options. The subtle wording; “your areas” connects with ownership. It means that the project schedule belongs to them too. Of course, never underestimate the power of mansions: “thank you” and “please” always come in handy. However, there is a caveat with this approach, it requires sincerity. People will notice if you say something you don’t believe.
Before I go, I’d like to offer some advice on how to build your project schedule. When typing the name of a task, whatever it is, it should be some kind of action (eg “re-delegate domain name” is good, while “perform hosting tasks” is a bit vague). Task estimates should never be more than 16 hours (if they are, break them into more tasks), but also avoid too many 0.25 hour blocks, that’s just overkill. Do your best to fill in the “current estimates” column, this can be used in the future to highlight tasks you have underestimated.