If you’re responsible for heading up a project be it for your team, your company, or even yourself, then odds are you can’t help but think in terms of milestones or features.

Honestly, if you’re working on something for yourself, this may not be as big of an issue, but if you’re working in the context of any larger environment in which you’re responsible for delivering a solution to a client, then there are a variety of ways that you may divide up the project in order to get provide some rhythm of delivery.

Over the past year, I’ve had the opportunity to work on larger projects in which I’ve had the ability to spend time thinking and experimenting with WordPress project management as it relates to delivering features (or milestones, to most of us), and I thought it’d be worth sharing here if for no other reason than to get others’ opinions on the two approaches.

WordPress Project Management

When it comes to software projects, managing WordPress projects are really no different than managing .NET projects, Rails projects, or any other software projects especially if you have a background in software.

I say this before jumping too far into this because there is something about the WordPress economy – and, really, the open source economy – that makes it appear to be “easier” to work with or “more flexible” to work with as it relates to delivering a solution to a client.

But the truth is that it’s not. To most people, it doesn’t matter what language, platform, or tools that you use. They don’t know, and it doesn’t matter. They have a problem, they need it solved, and the rest is all the same to them.

So, to that end, developing for one platform versus another makes no difference, but there are strategies for delivering software that transcend the languages, platforms, and so on that you’re working on that can help make your life easier by setting expectations for the customer.

Slicing and Dicing

I was first introduced to this particular method where I previously worked, and I really enjoy this particular approach to releasing software.

Slicing and Dicing The Milestones

Slicing and Dicing The Milestones

In short, the idea is that each vertical represents a feature or a milestone and then each time you deliver a portion of the project, you release code that touches each of the verticals.

Sure, for larger verticals, there are going to be things that are not seen until later in the project. For others, features may be complete by the first deliverable.

On the other hand, this particular strategy won’t necessarily work for every project. Sometimes, it’s better to list out the features, and begin tackling them one by one.

One By One

In this particular strategy, the features are on the horizontal axis and the idea is that you focus on one feature at a time.

Working on a Milestone One By One

Working on a Milestone One By One

The order in which you work on features are somewhat arbitrary – start with the smallest and work to largest, or vice versa – but speaking from experience I do think that there’s something to be said for starting with the largest aspect of the project.

I say this because I believe that if you tackle the largest part first, you’re inevitably going to write helper functions and other utilities that will play a role in the smaller functions whereas if you start with the smaller features, you may have to bounce back to them with each milestone refactoring some of the code (or just let you code turn into spaghetti code or some mish-mash of code that works, but doesn’t work as elegantly).

No Silver Bullets

There are definitely more than these two ways to tackle a software project, but these are two with which I’ve been working over the past year-to-year-and-a-half as I experiment with what I find to be most effective in a given situation.

The truth is, at the end of the day, our job is to deliver working software to others. Ultimately, we should want to mitigate the amount of time that exists between deliverables, and that’s where project management comes into play.

That said, I do not believe that there is a silver bullet project management strategy. Instead, I think there are certain strategies that work better in some situations than others.

These are just two of the ones with which I’ve been experimenting over the past little while. But with that said, I am curious as to other strategies you guys may have, so feel free to share ’em.