Above all, it should be mentioned that there's no single method of software development that is suitable for all software projects. The qualities of a good software development methodology are the features that provide solutions to the problems facing a project, hence software development methodologies that focus on providing solutions to non-existent problems will have less relevance than methodologies that are designed to address the problems that do exist within the project. The first question to be answered shouldn't be about which methodology to choose, but what are the problems faced or likely to be faced by the software project?
Although it may not sound like a feature, having an element of formality will help to keep the project on track by providing a process that people are aware of. With formality come rules and requirements, which in turn produce discipline — required by the development team and the client.
It is the outcome of formality (requirements and discipline) that benefits projects; not only does it make sure that the development team knows what it should and shouldn't be doing, it also points out to the client what they need to be doing — especially when the development team needs their input to progress.
As a freelancer or contractor, you may work alone directly for the client or as part of a team. Both of these working methods should have some element of formality, even if only to cover your own back. Considerations could include:
- Appointment of decision maker(s) : It is agreed by everyone involved in the project that only this person or people have the authority to make decisions relating to the direction of the project.
- Feature requests written in a specification document: Making sure that each feature is clearly worded without any scope for ambiguity.
- All change requests to be made in writing and dated with the signature of an appointed decision maker for approval: This would occur after the decision maker has been made aware of the implications of the change request — e.g. delay in the project delivery, risk of additional testing requirements, etc. Any implications should be written into the description that the change request authorization document. This formality provides accountability that avoids scenarios involving you being asked to make changes that haven't been requested by the client; this is a significant issue when people involved in the project have their own agenda that's not compatible with those of the assigned decision maker(s).
- Time sheets: Having a written record detailing activities relating to the project will provide the client with a better understanding of effort and time being invested. This helps to control the client's understanding of how the software development process works and avoids situations where the client makes assumptions about timeframes and costs for features that sound easy and quick to develop, but in reality are time consuming and difficult.
- Meeting documentation: Making sure there is a formal agenda for meetings and that notes are created to document all issues covere will help to make sure that everyone involved can attend the meeting fully prepared and that time isn't wasted on covering irrelevant topics and repeating anything already covered. Keeping a record of all meeting documentation also allows you to backtrack later in the project to identify what was agreed in meetings if required.
- Specifying availability: This factor works both ways, where you need to be available to do the work and the client needs to be available to provide resources such as information and content you need to get the job done correctly and on time. Having an element of formality to identify the availability of both parties will avoid situations that affect the progression of the project such as your other project commitments becoming a barrier or where the client may take a holiday that results in a delay to your work due to a requirement of information not being met. Similarly, having a formal agreement relating to your availability helps to avoid the client making assumptions about you not spending enough time on their project — especially where the client doesn't understand the complexities involved in developing the software features they have requested.
The need to adapt for unexpected or changing situations shouldn't be underestimated; not even for projects that appear to have concrete specifications that are unlikely to change. Although formality provides advantages for structure and discipline in the project's development, too much formality can prevent the type of flexibility required to successfully react to unexpected circumstances. An example of this would be where there has only been one decision maker appointed for the project who isn't contactable when an important decision is required; having the flexibility for someone else to make decisions when the primary decision maker is unavailable would help to avoid this situation becoming a problem.
There are many ways in which your software development methodology can incorporate flexibility:
For the most part, software development is about writing code. Code is only a valued contribution if it does the job — and a major bonus if it is developed to be maintainable. Unfortunately, writing code, and especially good quality code, requires programmers to be "in the zone"; a reference commonly used to describe the state of mind where the programming problem's solution can be clearly identified, hence resulting in the programmer being highly productive. Not everyone is a morning person, meaning that a lot of people are more productive towards the end of the day. With software development relying on the quality of the programmer's output, the traditional formality of set 9 to 5 working hours enforced by most office based businesses becomes counterproductive to getting the most output from the programmers on a project. It is for this reason that flexibility of working hours can have a positive impact on projects in terms of the delivery and cost by producing more output with less time requirements by only investing time that is highly productive.
It is technically true that there is no wrong way to develop code as long as it works and the outcome meets the requirements specified for the desired software. With this in mind, there are still bad and good methods to develop code in relation to business strategy— the better code having advantages in adaptability, testing, security and other issues. So although any method of programming will eventually get the job done, better methods of programming will reduce problems, costs, risks and time requirements to make you more profitable and able to meet criteria for quality and completion time. Programmers have already identified so called code patterns that are a good fit to meet the demands of software projects, hence you can learn about these patterns and adapt them to fit your (or your team's) programming style and project requirements. Think of code patterns as being similar to writing, in which there is a pattern that you use for splitting your content between paragraphs, chapters, diagrams, etc. - all useful tools for specific parts of your writing.
Code patterns shouldn't be flexible in the sense of consistency for programming style, but they should be developed to be flexible to withstand changing requirements. This means investing more time to write code that is reusable and adaptable for the long term. Although this requires more effort initially, the benefits become apparent later in the project when alterations and additions can be implemented in a few lines of code with minimal time and skills. The skills element of this benefit also means that what would otherwise be considered to require advanced programming skills can be given to junior programmers to reduce the project's costs and release more experienced programmers on the project for other tasks.
Project specifications change for many reasons, therefore your project's methodology should reflect this by providing a process to facilitate changing specifications. This could be in the form of breaking the project into release milestones where formal goals are identified for each release with the ability to refine the specification for future releases, or where an approach is taken to developing the software that refines it until the client is happy. The important consideration is to make sure that whatever process you use to reflect changing specifications also makes it clear what changes there are to the costs involved.
Where you need to hire people who have skills or time you don't have, it is worth considering whether sub-contracting or employing is the best option. When budget is a concern, sub-contracting could be the safest option; providing the flexibility to only pay for the hours required — as opposed to employing people where time waiting for the next phase of the project to commence will still cost you in wages/salaries. Contractor fees are more expensive on a per hour basis, but they don't have any of the wastage and hidden costs such as employee insurance, training and equipment. Although you should make sure that your sub-contractors are legally considered to be contractors to the project and not under your employment — in the UK this is called IR35 and is worth reading up on.
Link: http://www.contractoruk.com/ir35/what_is_ir35_rules_explained.html
Working on a prototype before developing the real product will give you a lot of flexibility to make changes without needing to worry about the implications of how change requests from the client introduce the risk of new bugs appearing in the code, or where inflexible code will cause problems to add the new requests. Prototypes can be created without the need to use specialist software; using PowerPoint or Keynote to create an interactive presentation will allow you to get the quality of feedback that clients would otherwise only provide once the software development has started, by which point it can become difficult to undo code you have created. An added bonus of prototyping with PowerPoint or Keynote is that these are general purpose software that the client is likely to have enough IT skills to add some of the changes they want, meaning less difficulties in you needing to interpret ideas the client struggles to communicate.
The art of planning for freelance projects is a fine balance between the extremes of absolutely no planning and too much planning. Heavyweight methodologies such as PRINCE2 and SSADM—two methodologies that are overkill for most freelance projects, make significant use of analysis and report writing activities to correctly define everything required before the software development begins. These are good in theory, but not so good in practice when it comes to executing the typical freelance project you're likely to get involved with. The reasons for this include:
The typical freelance client wants to see results fairly quickly. The level of planning detail demanded by heavyweight methodologies add a significant amount of time to projects that freelance clients aren't likely to be patient enough to wait for.
Although the purpose of analysis activities in heavyweight methodologies is to identify the problem and the most suitable solution, many freelance clients don't understand enough about their requiements in order to give good quality information to fully identify the problem and solution.
An example of this is almost every small business wanting a website — these businesses are primarily motivated to purchase a website because they want a presence on the Internet to be like everyone else. The sad reality is that most of these businesses fail to make use of their websites and consequently lose money on their investment because in many cases, a website is least suitable option for the problem they have poorly defined.
While these businesses say they want a web presence and make the assumption of needing a website, what they really need is a way to make sales and enquiries via the Internet; of which options such as Amazon, eBay and specialist directories such as Tutor Hunt are a much better option because they provide both the platform and the audience without the associated software development and marketing costs. For many businesses who target consumers (as opposed to other businesses), having a Facebook page will have more marketing success than a dedicated website. Even where the creation of a website is justified to provide confidence to the client's customers, this type of business will often request a large website with unnecessary features, when what they really need is something very simple to present basic information needed by their customers. This is a clear example of how a lack of knowledge and ability to describe the main problem leads to an inadequate analysis that proposes an unsuitable solution.
Most small startup businesses, which are likely to be the main source of your freelance work to begin with, don't have huge budgets. The sophistication of heavyweight methodologies adds significant time overheads to kick starting projects — so much that the amount of time required to do a fully detailed analysis such as with SSADM could eat up the entirety of the client's budget before you get to write your first line of code. This factor alone would rule out the use of detailed methodologies for most freelance projects, regardless of how suitable they are on a technical level for solving the problem.
With the majority of clients not truly knowing what they want or fully understanding the problem they are trying to solve, combined with changing factors in their business environment, you will often discover that the scope of your projects change and expand throughout their lifecycle. It is not uncommon to find what was initially intended to be a week's worth of work turning into a project that spans months or even years. With this type of project, a lot of planning that occurs at the start of the project becomes redundant midway through the development, meaning that time and money has been wasted on analysis activities that have no impact on the project delivery. Furthermore, each change results in the requirement for the existing plan to be updated to reflect changes in the requirements, hence further increasing the time and budget required.
With all of these factors weighing against the use of planning in your freelance methodology, it would be easy to assume that planning is a bad thing for freelance software development. The truth couldn't be further from this assumption — although it's safe to say that the detailed planning championed by the heavyweight methodologies are overkill and ultimately unsuitable for the majority of freelance projects, there is still a need to have a form of planning that is lightweight for activities to be executed efficiently and profitably on a smaller budget, but adequate enough to define expectations and keep the project on track to meet key milestones and completion.
The level of planning and analysis required for freelance projects is dependent on the project in question, with the primary factors dictating the required effort being budget, time and complexity. The main planning and analysis considerations for all projects should include:
Clearly identifying the problem to be addressed without influence of how the client is describing the requirements in relation to a preferred solution.
Understanding the people that the project relates to will form a large part of identifying the best solution to the problem, as well as understanding how to manage the client and their employees. The culture analysis shouldn't be restricted to the people directly involved with the design and development of the project, but also to people outside of the project development such as the end users of the software such as the client's customers and suppliers. This activity helps to identify social barriers posed to both the software development process and the end product, both of which will highlight which of the potential solutions would be the easiest and least risk to implement.
In terms of the previous website example, a culture analysis would reveal that the target audience of all businesses can be found on pre-existing web platforms, whether it be eBay, Amazon, eLance or Tutor Hunt. This analysis would also identify how these potential customers are already familiar with the pre-existing platforms and having enough trust to make payments through them; all of which pose a significant barrier to building a custom built website to do the same job. Furthermore, this analysis would also identify that regardless of how good the software provided for content and e-commerce management, not all businesses have the capabilities to execute the required ongoing content strategy to make their website a success — in some cases giving the ability to change and add content on the website can lead to some clients adding poorly written content that destroys brand credibility.
The technology relating to the software shouldn't be underestimated. Care should be taken to ensure that the vision for the solution is in line with the technology that is both available and in use. Projects should avoid over ambition by being designed to require technologies that are not in use by the target audience — one example of this would be developing a mobile app that requires higher than average phone hardware and OS specifications, therefore limiting the number of users who can use the app. With this said, which is especially relevant to mobile apps, thought should also be given in relation to the expected state of the market by the end of the project completion. Where mobile apps are concerned, hardware specs rapidly improve every year, with the average phone user upgrading every two years. This has a significant impact on projects that have a long duration; with the average technology specification in use at the end of the project being significantly different to those in use at the start.Environment evaluation
Factors that are outside the control of the client lead to situations that affect the project requirements. Understanding the environment that the client's business operates in will lead to a better understanding of how the definition of the problem may change throughout the duration of the project. By understanding how the environment will affect the project, new considerations can be identified for the requirements of the software's programming implementation for flexibility that will allow accommodation of new feature requests that result from changes occurring in the client's business environment.
The element of risk should never be underestimated; whether it's factors that have a direct impact on the code or whether it's the risk of the client not paying their bill. Understanding the risk allows for procedures to be put in place to eliminate or minimise their impact should they occur.
Identification of options to solve the problem without bias to any individual solution, regardless of what has been suggested by the client is important. Viability should be considered as the achievability within the timeframe and budget given by the client, as well for the end result being realistically capable of producing the short and long term outcomes desired by the client.
Breaking the project into smaller objectives makes it easier to show the client how far away you are from completion, as well as to identify if you are on schedule — and for action to be taken early if not.
Having an estimate for the delivery of milestones and their breakdown tasks is good for your own time estimates as well as for allowing the client to see regular updates on how the project is progressing.
Factors requiring planning and analysis need to relate to the type of client the project is for, the people you will be working with in the client's organisation and even the team you are hiring or working with. This side to planning and analysis methodologies is completely focused on people oriented issues; referred to as a soft methodology, this is different to the previously mentioned methodologies and activities whcih focus purely on the technology implementation. People issues should never be underestimated because they always have an impact on the progression of the project. The same project for two different clients could have a significant difference in cost and time purely based the people factors relating to the client's employees and their company culture. Important soft elements of your methodology should include considerations for:
Every business is different, so it's important not to assume that what works with one client will work with another. People are creatures of habit, and understanding this will provide you with an advantage for learning patterns of behaviors and characteristics in your clients that will allow you to predict their actions and reactions to situations that emerge in the project. This foresight is important for allowing you to be proactive in avoiding problems — instead of being reactive to problems after they've occurred.
"If those who are sent to draw water begin by drinking themselves, the army is suffering from thirst." - Sun Tzu, The Art of War
Soft methodologies such as Peter Checkland's Soft Systems Methodology (SSM) address this issue by having a specific process to model the different roles people play in situations. The model refers to situation role players as actors, owners and customers, describing each in relation to their environment, experiences and perspectives that influence how they become involved with the project. By understanding the model, you are able to develop an understanding of their motivations and limitations so that you can identify the best way to approach the project with minimal friction, disappointment and confusion simply by communicating the right message to the right people. After all, adequate decisions can only be made by appropriate people who have the current insight and authority; you are simply wasting your time, if not also opening the door for bad decisions or expectations, by speaking to the wrong people about project issues they shouldn't be involved with. This process also forms a solid foundation for setting expectations that the project performance will be measured against.
When it comes to setting expectations and performance metrics by which the project performance will be judged by, the first thing that should come to mind is to keep objectives SMART — specific, measurable, achievable, realistic and timely. SMART objectives should be the foundation of your plan for setting the right expectations so that your performance metrics can be met. People with experience in any type of engineering or management field will have learnt quickly that it is much easier to promise than to deliver, with software development being no exception. The saying of "loose lips sink ships" is a good phrase to have embedded as part of your team's mantra so that situations can be avoided where people accidentally say things in front of clients that needlessly increase expectations.
The risk to avoid in all software development projects is providing any type of suggestions that fall outside of the SMART agenda. This happens a lot easier than it may sound; especially if you have junior software developers working with you who interact with the client at meetings or through e-mail. This is more common in digital creative projects that involve software development, where it is easy for people to get over enthusiastic and under estimate the complexity and time requirements of their ambitions. In these scenarios, what is expected to take hours to create can turn out to take days or weeks, resulting in projects being delayed, budgets exceeded and most critically the project team failing to meet performance metrics, potentially leading to the client discontinuing the project. A form of soft methodologies such as SSM is required to control this type of situation to avoid emerging difficulties leading to conflict and blame. In turn, software developers are able to avoid distraction by team/client politics, resulting in more of their time being spent productively to progress the project.
It would be naïve to think that your projects will be executed and completed without conflict of some form. Not all conflicts are severe, but all are conflicts nonetheless. All conflicts originate from agendas or communication breakdown, with the majority resulting from the latter. Avoiding conflict in most cases comes down to having a clear communication strategy — especially when you are dealing with projects that involve multiple people. Make sure that the right people receive the right communications, complete with the ability to remind them and record agreements in writing. Time is a factor of all projects that distorts perceptions of agreements; the more time involved means the more scope there is for people to forget or be selective in remembering the finer details. When agreements are documented clearly in writing, problems of selective and distorted memory of agreement details magically disappear.
The other cause for conflict are the agendas of people, which are always something to look out for. These conflicts are difficult to avoid due to the person or people with the agenda actively steering the project in the direction for conflict. Understanding what these agendas are will allow you to plan in advance an adequate response to the situation. Sometimes the solution lies in identifying how to appease the people with the agenda without derailing the project, whereas other times it may be best to isolate the people who are causing problems so that their impact on the project's progression can be minimized. It should be noted that there is a fine balance between appeasing people so that embroilment in politics can be avoided, and making harsh decisions that may offend people. Always understand who you are answerable to so that your efforts can be focused on appeasing them; when it comes to conflict caused by agendas, many problems are caused by people bending the truth or telling outright lies.
Politics between you/your team and the client are enough for you to be concerned about without also being involved with the client's internal politics. Make sure not to willfully or accidentally engage in client politics, which includes making comments on individuals, decisions or situations that don't directly involve your work. It is very easy to accidentally step into a client's internal politics by commenting on their activities or individual employees. Even if only jokingly, this can lead to perceptions of you taking sides in their affairs that result in mistrust creeping into your relationship with employees of the client who have a direct impact on your ability to work on the project. Your embroilment in client politics adds unnecessary barriers to meeting the project's performance metrics; in the most extreme cases can cause a complete failure of the project.
Something that should be involved in all soft issues is the documentation of agreements. These agreements don't magically provide solutions to the technical elements such as resolving broken code, but they are a framework for keeping the project on track to an agreed specification. This benefits everyone, helping to remind develoers what needs to be done, while making sure that the client has a reference to what they've requested. Having a policy for documenting agreements also helps to avoid conflicts caused through agendas by clearly identifying who is requesting alterations to the project specifications. This allows for any devious actions to be traced in a way that allows the client to take action and avoids you being held accountable.
The foundations to all soft problems are in perception, and an important part of how perceptions are created is through communication. Good communications can mean the difference of good ideas being correctly interpreted as they are intended, or incorrectly interpreted as bad ideas - resulting in the software being produced without features that can make the difference between its success and failure.As a minimum, the use of document templates for Microsoft Office or Libre Office should be considered for many communications; especially those that need to be documented. The use of templates for communication allows for consistency as well as to remind people who are writing communications of what they should be asking or providing information about. Examples of templates that can benefit communications include change request documents, progress report updates and requirements analysis communications; all of these communications can benefit from improved quality by prompting writers to detail who, what, when, where and why. Consistency in template formatting also makes it easier for people looking to find specific information if the template format is designed to have a specific section that is easily identifiable when speed reading.
Having a plan to execute and resolve all of these issues will allow you to manage your projects in a way that avoids, or at least minimises, the risk of people issues becoming barriers to progressing the project.