Some tips on software project planning


Whether you are a freelancer or a developer in web studio or some company you will definitely face challenges in project planning, whether it’s your personal projects or your employers. It is not always possible to have everything planned for you, especially when you are working for a small business, freelance or in small team, simply enough because there will be nobody to do the planning for you and you just have to do it all by yourself. Here is some tips that might just help along the way.

1. Plan only for foreseeable future

When planing a software project you will meet many “what if’s”. That means exactly what it says it means – you will end up in branches of functionality where you absolutely know you will need to expand in later on. What’s important in such situations is not to go too deep in the rabbits hole, or you will simply lose scope of the actual project and in place of one concrete software project you will end up with many less or more equally sized ones spread out in several branches of the original project. It’s a mess to plan, it’s a mess to implement and it’s certainly a mess to manage.

2. Deadlines are important and necessary

Whether you are required to have them or not, for example, in your personal projects, deadlines must be present in every project, big or small. If not employers or clients deadlines, then your personal ones. They will help you to keep yourself in order and to hold focus on the task you are actually supposed to do. Deadlines are also a good motivator – when you say your employer or customer that “it” will be ready in two weeks, you better get it ready in two weeks or else you will just make yourself look very unprofessional. Only things that allows you to bypass deadlines are reasonable 3rd party dependencies everyone is aware of and that you just can’t finish without in time to meet the deadline.

3. Keep a record on everything

This includes but limits to proper software specification. Every single functionality, big or small must have been properly documented. Every. Single. One. Even if you are a reasonable and decent person yourself, it does not necessarily mean your client is the same. Having a paper to hold on to will not only help in legal disputes but also to hold your ground in arguments with client. Yes, we all know such clients – they think that particular button right there, with that ridiculous border” has to do some epic magic on site, and sometimes the type of client is you can’t reason with him. Proper documentation will help to hold your disputes chained in pillars of reason. Next thing you should always keep a track on is meeting notes and email communication. It might prove handy to reason with clients which just don’t seem to be willing to understand how the software development works. “I want this button to open trans-dimensional quantum gateway to Alpha-Cephei and transport all my childhoods dreams over there in that exact moment. And i want it for free of charge, because such button exists in design wire-frames”. You accepted that design or it might even be drawn by one of your designers. What now?

4. Keep the paperwork partitioned but not annoying

This is about both documentation and splitting that documentation out into task list. Oh, yes, documentation also helps you to build task lists and assign deadlines for them. It’s quite easy to manage planning this way, because after each project you see where exactly you failed with the planning part in previous project and the solution for that to never happen again will now become obvious for you. Split  the documentation in smaller descriptions over parts of functionality but keep it tasteful, easy to read, describing as much as possible in amounts of text as short as possible. Do the same with tasks. It is known to be easier to know where you are going when you know where have you already been and where do you have to go next. It is essential to not overdue the partition thing, as it will create unnecessary management load on those who will have to deal with it, also to yourself. Unfortunately there is no clear rules here like “a task must be maximum 200 characters long”. It depends on the team and unique micro-climate of your  working environment.

5. Keep the customer in loop of the latest

Having a project developed for half a year, then released for testing to client and then got rejected? Obviously. What you really need to do is to keep the customer in loop of latest changes and have a testing environment ready for your customer to become known with the project as soon as possible. Now make it twice as soon. Getting feedback from customer is important, but what is much more important is for customer to get known with the system, its possibilities and limitations. It will help a lot when you need to finish the project at some point. Also, inconsistencies and faults will be identified a lot sooner than just dropping the system on head of customer after half a year of silent development. Also, it wont harm to have a meeting once or twice in a week with customer to help interpret the documentation and present latest changes.

6. Some liquid cooling for your brain cells, maybe

This is psychological. Just find yourself another small or not so small project to get your hands on to few times a week while working on a larger project, few hours a time. Working for long periods of time on single project will only get you bored and melt your brain. It’s neither productive nor does it makes yourself happy about it. So when planning deadlines for your project, take this into consideration. The project will be delivered later than might be expected, but you will keep your karma and team happy.  And if software development does not make you happy, so why the hell should you do it at all, right?…

7. Have an open toolbox

This is about golden hammer anti-pattern. It also affects project planning. It is clear you are the best with the tools you master, but it is not always the case for the project or customer. Having an open toolbox means you should take switching of your favorite hammer to another not so favorite hammer in favor of the project into the consideration when planning the technical side of a project. For example, Java might not be the best and most effective solution for corporate business card website. And, PHP unfortunately might not be so effective multi-process platform for heavy load real-time data processing applications. It might prove to be invaluable for team to be open-minded in trying new things.

8. Design before development

Having design ready before the actual application is even began its life-cycle might prove invaluable approach for effective project development. Developers are human. Developers get confused easily when there is lack of some particular detail in projects documentation. Let the developers take a peek on design. Sometimes seeing the real UI implementation of the project might just dissolve the confusion about that particular poorly documented feature.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>