Today’s post is on something a bit different but still very much relevant in the web development world: project management. Now, I’m not all that old and I haven’t been a web developer for all that long (about 6 years in total, 3 actually getting paid ;-) but I have had the opportunity of working for a medium-sized media company with a development team of about 25 developers, a small 5-6 person development company (3 developers), and as an independent contractor.

When I began my career at the medium sized company, I initially saw my project managers as a pain in the ass. All I was interested in doing was coding. I had my own ideas of how the project or feature was going to be done and I thought that I could handle deadlines and project requirements better than they could. Was it really necessary to ask me multiple times a day what I was doing and what percentage of the project was still left to be done? PM’s gave new meaning to the phrase “avoid like the plague.” In all honesty, I wondered why in the hell these people were even hired to begin with. I just could not see the role of a project manager as being all that important.

Of course, after a bit of development work and experience doing projects with and without them, I found myself having moments of… “OMFG…where is my project manager?” As developers, void of project managers, we often get carried away with the art that is code. We plan for one thing but, weeks post-deadline, end up creating something entirely different. Does it work? Usually. Is it beautiful? Maybe. Is it what was promised to the customer? Well, no.

I’m not just talking about instances where a simple login feature ballooned into a grand hierarchical authentication scheme. I’m also talking about those projects, that for some reason or another, we just despise working on and push off completion; sometimes even writing substandard code just to get it over with. And don’t forget those projects that are just so complex that we’re not even sure if we are starting at the right place, much less dedicated to a deadline of any sort.

It seems that the problem here is not one of competence—most of us could, if we really tried to, stick within initial specs and scope. To me the problem lies in the fact that without the role of the project manager on the team, we lack the time and task management designed to keep us on track. We are trained in how to solve problems of logic through good coding principals and design. We are artists. Our canvas is digital and we sometimes let our creativity and desire for compounding beauty interfere with the job we were hired to do. We are not trained in restraint; the project manager is, at least in theory.

Depending on your experience, I suppose this next statement may be gospel or blasphemy, but to me, it is gospel all the way. The successful completion of any project hinges upon a solid development methodology based in clearly defined project goals, block specifications, complete use cases, and the division and distribution of task level development. A good project manager will be able to take high level design specs and goals from a product manager or customer contact and break them out into clearly defined and manageable building blocks. Each block can then be broken down into feature/requirement sets which can finally be tasked out to the developer/s for completion. This is the job of the project manager, not the developer. Developers should only be given spec’d out tasks with detailed use cases and an explanation of exactly what should be done. It is then up to the developer to determine how the task will be done.

Now, this is not to say that developers are not to be involved in planning or design phases of projects; by nature, they have to be. However, design and planning meetings involving developers should be focused on the technical goals of the project or block, not on management and product/customer level concerns. These meetings must be narrow in focus and should have a clearly defined result. For instance, determining the database schema for the project or settling on a development framework. The layer of abstraction here is critical in keeping the project within scope and to prevent developers from expanding on or reducing the project deliverables. Once the meeting objectives have been met, project managers should then be able to chunk and task out the technical specs to the team of developers.

Now, up until a little while ago, I hated the word “task.” Every morning I would check my email and see, “You have been assigned a new task from…” after which my head would sink low and I would seriously contemplate my career path yet again. I would constantly wonder why everything had to be a task: a task to change a misspelled word, a task to add 5 pixels of spacing to the end of the page. Wouldn’t it just be easier to send me an email or IM or for goodness sake, just turn around and tell me? Surely this couldn’t be the Zen that is programming? However, recent experience has taught me that, by God, we all need tasks just like we all need competent project managers!

Task assignment, and by extension, a good task management system (note that a task/project management system is very different from a strict bug tracking system) is an absolute necessity for project management. Proper task etiquette enabled by a solid and complete project management system serves many purposes. First and foremost to developers, it serves as our grocery list. It tells us EXACTLY what we have to do, when it needs to be done by, and contains a history of the problem or feature (most PM system tasks have comments/histories and file attachment capabilities). From the management side of things, a PM system will track the number of hours developers spend on each task which can then be used for billing or other performance metrics. It also can serve as a yardstick in determining the level of project completion by showing a variety of statistics based on ticket assignment, time used, percentage of tasks complete for a given project, and developer performance.

Not to sound too preachy (or take too much of an aside), but I have come across a number of good techniques gathered from the various project managers and lead developers I have worked with in the past that I would like to share and recommend that people use.

Quote Tasks

Make use of quote tasks. It may take a little more time and to some it may seem really useless, but in the end it will serve as a good measure of your time estimation abilities and speak to the thoroughness of your work. The way it works is that for every task you are assigned, unless fixing the problem will take less than 10 min., in the comments section you should list the files and line numbers that you will need to make changes to in addition to a brief one liner explaining the expected change. You then assign the ticket back to your project manager to quickly review. If your time estimate falls within the allowable project time, then you will get the task back and no matter how many days or weeks may pass, you will know immediately what needs to be fixed and where.

Notate Completed Tasks

When tasks are complete, you should list each file and line number range that you made modifications to and provide a one or two sentence description of changes (in addition your regular brief outlining the totality of changes). This makes tracking changes easier for those who may follow you and serves as a written history in a developers words of exactly what was done for the task.

The Six-Hour Work Day

One small tip on time management and allocation I learned from my last PM was to only allot 6 hours of estimated work in a day. He said that the remaining 2 hours are spent on bathroom breaks, water cooler conversations, task switching ramp up, nerf fights, etc. At first I thought this was strange. Could bathroom breaks really take up 2 hours of my working day? But as I was tasked on this schedule, it seemed to work out pretty well. While I didn’t exactly lose 2 hours doing random things, what did happen was that I was rarely under pressure to squeeze out tasks leaving me less stressed and able to produce better quality and more thoroughly tested code and documentation. Funny thing, comparing a “6 hour” work day with the regular, “get as much work done in the 8 hours you are here” approach, I felt more productive and competent under the 6 hour routine. Give it a try, you may be surprised.

Developers as Project Managers: Warning

Developers should never be placed in the role of a project manager; creating and managing their own tasks. However, sometimes there is little choice (little company resources, sole operation, etc). If this is the case, expect that as a developer you will be spending probably 1/4-1/3 of your day planning and managing tasks; not working on them. Be sure your boss knows this if they are not willing or able to task out projects properly to begin with. This is really for your sanity and for the thoroughness that comes with being a competent developer. Now, in the rare case where you as the developer are tasked with actually taking customer specs and being told to simply get it done, placing the entire development life cycle on you or your team’s shoulders, I strongly suggest that you ask management to hire a project manager. If that is not possible then maybe you should be dusting off that resume because project specing, chunking, and higher level project management duties like those are not your job. There is a good reason developers are not PM’s and PM’s are not developers.

The Devil’s in the Details

Nag, nag, nag. If you get assigned tasks that are too general in scope and you have any questions about exactly what it is that your PM or boss is asking for, send the ticket back and ask for further explanation. It usually only takes a few times doing this for your boss to get the idea of what information you need to get your work done right. Remember, training goes both ways; you learn from your boss as much as your boss learns from you. It’s better to take the time upfront and get accurate and detailed specs than for you to guess and have to go back and rewrite something down the road.

All that being said, there are a number of development methodologies out there to help you and your team develop software in an efficient and smart manner. Now, as I’ve made crystal clear, I’m not a PM so I don’t claim to be an expert on any development methodology, but I take particular affinity to Agile development methods like Scrum. Any methodology where you as a developer are protected from business processes (changes in specs/customer expectations, etc) external to your core job function is a winner in my book. Avoid the traditional waterfall and cowboy coding approaches as they are highly inflexible and in the former case, plain stupid as a development methodology for any business.

So there! I hope I’ve been able to give a little personal experience to you developers out there (and you managers) who may be a little too code-centric. Don’t ignore the management side of your business. It can save your sanity and make you a better developer in the process!

Posted in: Articles, Development, How To