| Creating software without a project schedule is like | | | | the 'catch-all' for tasks which don't neatly fit into any of |
| driving a car without a seatbelt; it can be done, but that | | | | the other categories. |
| doesn't mean it's a good idea. Before we go any | | | | I also like to create a 'summary and charts' page, but |
| further, I should say that this article isn't about why you | | | | this is gilding the lily. I find that it's handy when my boss |
| should have a project schedule. If you need that kind | | | | asks me "how is the Widgets project going?" I can |
| of convincing, may I suggest a great article by Joel | | | | answer "overall, its 92% done - we are on track". Its |
| Spolsky called Painless Project Schedules. In fact, the | | | | also helpful knowing how many hours have been |
| style of project schedule I use is derived from his | | | | allocated to different team members. One reason I do |
| method. | | | | this is because I have a bad habit of taking on too |
| What I would like to talk about is how Google | | | | many technical tasks which really should be going to |
| spreadsheets can be a real treasure when it comes | | | | the production team (what can I say, I used to be a |
| to making your project schedules. Like many tales, this | | | | programmer). |
| one begins with a cause to be championed. Not so | | | | Having a project schedule is great, but the unfortunate |
| long ago, I worked at a company with three | | | | reality is that most people could care less about it. |
| programmers. It was my job to make sure projects | | | | From my experience, upper management generally |
| were delivered on time and to spec. Resources at this | | | | aren't that interested in the detail of the schedule, but |
| company were very tight. This meant that any time | | | | they do appreciate its existence. They will more often |
| savings I could get by streamlining a process, I would | | | | be interested in milestones and delivery dates. |
| go for. | | | | The other hurdle is getting programmers to use the |
| In the past I had used either Microsoft Project or | | | | schedule. Most of the time I've found programmers |
| Microsoft Excel for scheduling. Putting my project | | | | aren't too keen on directly participating in the |
| schedules in Google spreadsheets offered a number | | | | maintenance of the schedule, but you must bring them |
| of perks. For one, the schedule was accessible from | | | | into the fold. Programmers are far more interested in |
| anywhere anytime (home, office, mobile, etc). Another | | | | cutting code, which is good - it's what they love to do |
| bonus was that multiple programmers could edit their | | | | and what they are there for. So how do you get your |
| relevant areas without any sharing issues. Also gone | | | | technical people involved in the project schedule? |
| were concerns about backups and where on the | | | | Basic people management skills really. People will be |
| company server the file should reside. | | | | far more inclined to do something if you ask them to |
| If you look at the structure of the project schedule I | | | | do it rather then order them to do it, and people are |
| use, you may think to yourself "it's so simplistic, surely | | | | more inclined to do something if they are given some |
| that isn't enough to cover a complex project?" But | | | | choice in the matter. To a lesser extend, that often |
| really, what more do you need? You write down what | | | | vague concept of 'ownership' comes into play here. |
| the task is, an estimate for how long it will take, who's | | | | What I often say to the programmers I am working |
| meant to be doing it, and how much of it has been | | | | with is something along these lines; "Tony, when you |
| done. | | | | have time, can you please go into the project schedule |
| OK, you got me - this style of project schedule does | | | | and update your areas. Also, for the life of this project, |
| have two major flaws. For starters, it's hard to figure | | | | I need you to go in at least once a week to update |
| out delivery dates, another problem is that its tough | | | | your areas". |
| carving out distinct milestone. But where this style or | | | | Over the years, I've found this approach works very |
| project schedule shines is in task management, you | | | | well for a number of reasons; there is 'choice' in there; |
| won't miss things, and as the saying goes "the devil is | | | | saying "when you have time" and "at least once a |
| in the detail". It's an excellent way for distributing tasks | | | | week" leaves some breathing room for people to |
| to team members. It also provides a very good | | | | manage themselves. People are always happier when |
| overview of where you are at any given time within a | | | | they have options. The subtle wording; "your areas" |
| project. | | | | connects to ownership. It means the project schedule |
| Personally, I tend to create my project schedules with | | | | belongs to them as well. Of course, never |
| only five phases (you can have more if you like). I've | | | | underestimate the power of manors - "thank you" and |
| found all tasks will fit into one of these categories: | | | | "please" always go a long way. There is a caveat with |
| wireframes/mockups, coding, project management, | | | | this approach however, it requires sincerity. People will |
| quality assurance, auxiliary tasks. Auxiliary tasks being | | | | spot it if you are saying something you don't believe in. |