When working on software development projects, there are certain things that I think every project needs. Sure, each project is different so there’s definitely a difference among projects, but in my experience there are a few things that are crucial to both managing a project and completing a project.

Honestly, when it comes to writing posts like these, I think our natural tendency is to do so from the perspective of a freelancer or someone who may be subcontracted or self-employed.

Though I tend to fit in the latter camp, I’ve found that the following tends to be true regardless of where you work – be it a big corporation, a small team, or even on your own.

Every Project Needs…

So what are the things that every project needs? Again, this is not an exhaustive list. These are things that I believe are core to running and managing projects both with local teams and remote teams, as well.

1. Communication

This cannot be overstated. I don’t care if the communication is via Slack, IRC, email, or apps like Telegram – you’ve got to do a good job of communicating with your clients.

Even after you’ve gathered all of the requirements and specifications and you think you know what it is that you’re supposed to build, it never hurts to continually verify the results with your client.


Yes, this implies that you may need a staging environment, but I – and others – have talked enough about that in previous posts such that it’s not worth covering in yet-another-post.

Personally, I have a tendency to over-communicate. The thing is, each client is different. That means that some prefer this constant mode of communication, so we’ve opted to hang out in Slack, others are more concerned with getting emails once a major feature is complete.

Both are fine, but make sure that you determine what it is that works best for you, your clients, and the project, and then go from there.

2. Bug and Issue Tracker

No matter how far you get into it a project – be it the beginning stages or the final deliverable – you are going to have bugs. That’s the nature of the industry, and there should be some level of expectation.

But with that comes the idea that you’re doing something more than jotting down notes in a notebook of the things that you need to fix.


Instead, what I believe to be more effective is to have a piece of software – like Lighthouse or GitHub – that allows you to set milestones, labels, due dates, and so on for issues so that everyone at the project level – both the developers and the stakeholders – have the ability to see what’s completed and what’s left to be completed.

It’s also useful to obviously be able to add things to the list, but perhaps not everyone should have access to that particular feature :).

3. Source Control

Since we’re covering bug trackers, I’d be remiss if I didn’t mention that a software project needs source control (Personally, I’m a fan of Tower and Cornerstone).

This is especially true in teams when you have people working on branches of the source code; however, even if you’re a single developer, it’s important to have frequently committed versions of the code so that you can easily rollback should something change along the course of the project.

Source Control

Secondly, branches aren’t just for teams – I’ve used them in standalone projects when I’m working on a new feature and deployed them to make sure I’ve correctly implemented them before merging them into the master branch.

But that’s a topic for another post.

4. Optionally, A Roadmap

Each project has a roadmap – sometimes they are in the form of a fancy chart generated by a Microsoft application, other times they are bullet points in an email or a markdown document.

Whatever the case, there needs to be a roadmap of features that generally include the must-haves and the nice-to-haves and the progress that’s being made as you work through the “punchlist” as they’re sometimes called.


Perhaps you can use Trello to mark the list, or some other OS X or iOS, Linux, or Windows app to manage progress. Whatever works for you, use it and make sure that your stakeholders are aware of how to use it, as well.

This way, everyone knows not only what bugs have been completed and what features are being worked on, but they also have a rough idea as to where the project sits from a 50,000 foot view.

What Else?

As I said, this list is certainly not exhaustive and I’m definitely interested in hearing what you have to say about it so please don’t hesitate to leave a comment on the things that you’ve found useful (or even unhelpful) and why.

Who knows – maybe it’ll help someone else (including myself) out in a current and/or future project.


Join the conversation! 6 Comments

  1. Good one! I do believe that all those things are critical, I always prefer to have someone in the project who can manage it and make sure it all ticks together (and no, im not this detailed person, lol) what I do believe is that the stages before project starts are critical, define the actual needs, the requirements, architecture and understanding of WHAT you build. In here too – over communication is the best (especially I feel it as an Israeli work with the US…) the research need to be spot on – knowing what we are about to do and good product work can solve SO MANY issues in the future…

    Great post, in full agreement here

  2. Communication? With clients? Who like know nothing about software engineering? Fur real? “Mew must be kitten me!”


    I dont do much client work these days. Back in the day, we used Jooml’r. Not to sound “crazy” but well… WAS CRAZY!

    Jooml’r is wonderful IF the client wants the firm to take care of the site. Well wonderful might be a strong term. Workable perhaps better. But for THEM to LEARN anything? OH MY GOSH. I deployed videos (LOTS AND LOTS OF EM!!!!) into their hosting as well as a sandbox build. Three requirements: “Watch, Learn, Experiment” Their workflow -> “No, No and…. No”.

    One campaign site I recall well. Was elected, still is in fact. Long story. Anyways… I get called into this BIG meeting. “We are told that you are not helping the team use the software”. I said, “Untrue”, in fact, for most modifications and content I am doing that work pro-bono because they dont take the time for me to walk them through. “Thats not what they are saying”. I said, as is in the white paper overview, there are videos online as well for everything as well as quick reference docs. “Yes, they say they watched them and its too confusing”…. Really. So I log in, show him the “hit stats” on the videos. Nothing. Never watched em’.

    Commune-eh-cat-ion’s are as good as the Commune-eh-cater’s

    In as far as source control… Lots of nice things out there. I very much wish I could use Visual Studio for all PHP work.

    With roadmaps, I think they are very important. I will use Word and Smartdraw or Mindmap in unison. Mindmap for overviews. Then break that down using word into a logical grind.

    Source control… well, depends on the task as is the case with roadmaps.

    Something “Off Topic” Tom:

    In toying with Customizer for a friends nightmarish Envato Theme something struck me. And it wasnt a football.

    Customizer does internal style sheet though one can do inline CSS as well. I loath both. Only time I do inline is when I am tired of typing into Firefox, Chrome, MSIE or Opera’s console to get things “right” then cut/paste into .CSS file.

    So I started fuddlin’ about and I am not sure its worth pursuing, want know your thoughts.

    Instead, I have it outputting a .CSS file that gets last priority in CSS enqueue.

    Now I realize for front facing user alterations this would require more thought. With Jooml’r the way it was often done is via a post fixed class concat. aka: linkcolor-blue and the options already defined in CSS file. They use a color picker select box what all on the front end.

    I dont even know if customizer is usable to front facing users.

    An obvious “Eggstention” of what I did here would be to bring the CSS file into customizer structured like. Essentially something along the lines of either using CSS comments as definitions of structure or what I was thinking an XML file.

    Its backend only really, but I wonder if its something the community would want.

    One of the gripes about Customizer seems to be its lack of “space” and overhead for complex theme variations seemingly becoming slow. This would solve both as its “on demand” lazy loaded basically.

  3. I’d be really interested in seeing how you setup your roadmaps in Trello.


  4. Officially confused…

    Custom Post type for animals. Did Taxonomy for categorization (not using my friends categories, meta box instead). Backend ooops. Umm, Administrative area :) all works nifty.

    Front end. One would “think” that when assigning the taxonomy to a menu WP would pull up the items from DB? So I saw this:


    Essentially seems to use a “blank page”, assign template to it????? Then put the actual custom post type taxonomy under that menu entry for that page? Then use the template to do the loop?

    Is this right?

    Not that it works… but is it right?

    Seems like a kludge to me?

    • If this comes off as rude or as harsh, I genuinely don’t mean it that way, but I don’t think I understand what you’re asking.

      What I’ve gleaned is this:

      You’ve created a CPT for Animals * You created a hierarchical taxonomy for said CPT * Everything works fine in the Dashboard – you can create animals and categorize them

      But then on the front-end:
      You want to assign a taxonomy as a menu item * To display the content of the menu items you have to create a page * You them assign a custom template to the page to display the content

      Is this correct?

Leave a Reply