Chapter 3

Bare-bones project management

Web app projects come in all shapes and sizes: small apps developed by sizeable formal teams in commercial enterprises; large apps developed by loose collections of enthusiasts; and highly specific web services created by multitalented individuals.

This chapter examines the organisational ingredients, the processes and people that contribute to the success of small and large web app development.

Project constraints

The project management triangle is the traditional model for illustrating the constraints of a project. The triangle describes the trade-off between scope, cost and time. For a project of a fixed quality, if one of the three factors changes, the others must also be affected. For example, an increase in the scope of a project, usually through the introduction of additional features, will increase the cost or lengthen the timescale of the project, or both.

img-3_1

If you find the triangle a little abstract, you may prefer to visualise the balance of factors as a see-saw, which is still not entirely accurate but illustrates the relationships more dynamically.

img-3_2

From my experience, this model better explains the reality of balancing an ongoing web app project, for a number of reasons:

Given these complex interdependencies, what practical steps can be taken to counter the inevitable changes that occur during the planning and development of a web app?

Action Useful For
Time Cost Quality Scope

Phase development
Rarely does a web app require all of the planned features to launch. Instead, only those that produce the minimum viable product are necessary in the first phase, as discussed in chapter 8. Postpone non-essential features until a later phase of development.

Outsource development
Contracting out parts of your web app only works successfully if the app can be effectively segmented into documentable standalone components.

There is a range of ways to outsource, from dedicated outsourcing agencies, through freelance auction-style websites, to informal negotiations with friends and colleagues. As the formality decreases, the lower cost is balanced against increased risk and additional organisational overheads.

Open source development
This can be considered as a special kind of outsourcing. In exchange for surrendering ownership and rights over part or all of the code, you may be able to enlist the help of developers across the world for no monetary cost.

As with outsourcing, unless you want to open source the entire web app development, this approach only works well if the web app can be neatly split up into sub-applications, any of which can be developed as open source.

SourceForge and GitHub are good options for starting and managing an open source project. However, a 2008 study shows the amount of open source code doubling every year, so your project will face tough competition for attention. Be prepared to vigorously market the worthiness of your project to cynical developers.

Seek investment
This style of financing, usually called seed funding, raises cash from friends and family, or angel investors. An angel investor is a successful business professional who makes investments in start-ups related to their industry, and may provide advice and business contacts in addition to the injection of cash.

Due to high risk in the early stages, these investments are relatively small, usually tens of thousands of US dollars, in exchange for a 5–10% share of the business.

Seeking investment before a web app is developed can be tricky. Despite the online publicity suggesting these funding deals are plentiful, it is usually easier to self-fund most small to medium sized web apps by bootstrapping: using the cash from an existing or secondary income stream, normally your day job.

Team size

The size of your project team will affect the organisational challenges you face. Address these issues early to minimise problems.

For the sake of argument, we’ll divide team sizes into three groups. First, there is the one person team, sometimes called the single founder. This is typically a web developer with some interest in interface design and other web subjects creating an app as a side project in their spare time.

Next is the small, two to four person team. Web app teams of this size are typically start-up companies formed by friends with minimal seed investment.

Finally, there are the larger groups of five people or more, who are typically established teams inside a digital agency or large enterprise, creating an app for a client or the company.

Team Size
1 2–4 5 Potential Issues
Lack of in situ testing (implicit testing of ideas, decisions and output)
Lack of encouragement/morale boost when needed
Difficulty in attracting funding (investors prefer teams)
Difficulty in creative solution brainstorming
Longer development timescale
Lack of specialism (user experience, graphic design, Ajax, etc.)
Less flexibility in development (e.g. pair programming, code reviews)
Reliance on individuals (e.g. illness)
Less agility to change direction
Communication overhead
Organisational overhead (e.g. documentation)
Lower buy-in/motivation (‘a cog in the machine’)
Potential for personality conflicts that affect productivity

While many of these issues are unavoidable, inherent qualities of your team’s size, others can be minimised with some prior consideration. Focus on the most potentially harmful issues that can be avoided.

Team size: 1

Without a doubt, the most important pre-production organisational measure you can take is to find a reliable friend and ally who can play the roles of muse and informal partner.

This person does not need to be technical; in fact, it is often better if they are not. Ideally they will be someone who you naturally spend time with (for example, a spouse or colleague), but even an online friend will suffice. The role of this person is principally twofold.

First, they are someone you can sound off to. They needn’t understand what you say, necessarily, but you need an outlet to talk about problems, ideas and decisions. Often, just talking about an issue is enough to highlight an obvious or alternative solution.

Second, they should frequently ask about progress. Again, this level of interest can be feigned, but it’s important to have someone to periodically annoy you about your app and highlight how much has or hasn’t changed during a particular period of time. Ideally, they can also informally test and give feedback on changes as they happen.

Team size: 2–4

In many ways this could be considered the best size of team to develop a web app, with fewer prominent issues to address than the solitary sole founder or the bureaucratic large team. Nevertheless, as soon as more than one person is involved, some level of communication and co-operation becomes necessary. Even though interaction won’t be a significant issue for a team of this size, it can still benefit from a communication plan.

Use a limited number of web collaboration and communication tools. It’s all too easy for a team member to start using an exciting new online tool with the expectation that everyone will join in. Before you know it, you have mailing lists, wikis, online spreadsheets, blogs, calendars, private social networks and multiple ticketing systems. As a result, information sits unread and stagnant in ever more forgettable silos.

It’s better to pre-empt the team’s needs as much as possible and agree on a suite of accepted tools upfront, which might include:

Have the team add bookmarks to the agreed tools in their web browsers and, ideally, subscribe to the RSS update feeds from each tool.

Team size: 5+

The detrimental upshot of a larger team is the collaborative overhead of the additional people. This can include:

These problems can be minimised through some straightforward practices and tools:

Project process

When was the last time you attended an extravagant project management expo or you experienced the exhilaration of discovering a new project management blog? Unlike most other aspects of web app development – audience research, user experience, business models, graphic design, coding or digital marketing – project process is something that most normal people don’t get excited about.

Nobody likes excessive rules and regulations, especially if they repeatedly slow you down and demand that you do something mundane when all you really want to do is get on with the brilliant idea that’s in your head.

I don’t believe that a disorganised person (and we nearly all are) can easily become slave to an organisational process, or that evolutionarily we are designed to do so.

Luckily, creating a web app isn’t like building a hospital or designing embedded software for a digital camera that is shipped and never seen again. You can make mistakes, you can work things out as you go along and you can change the direction of your project if it’s not working out. Even so, as the old saying goes, a little risk management saves a lot of fan cleaning. And yes, I just used the phrase ‘risk management’. Please don’t hate me for it.

Much of the risk management is covered by the process outlined by this book: the initial set-up of your team and environment (Section 1); the strategy and feature analysis (Section 2); the interface design (Section 3); coding and testing (Section 4); and marketing (Section 5).

Traditionally, this process would be completed serially using the waterfall model. This is where each stage is signed off as finished, laying a seemingly solid foundation for the next stage. It is now widely accepted, however, that due to our lack of omniscience and limited capacity for planning, an iterative model produces better output.

Iterative development

An iterative process relies on our ability to successfully focus on something for a short period of time, and takes into account our inability to accurately visualise and predict how theory becomes reality. By taking short, iterative steps, we can focus on creating brilliance one move at a time, and can evolve our app as we get a better feel for the features that succeed and those that don’t turn out as we hoped.

img-3_3.jpg

The iterative process happens on two levels. At the higher level, new app features are developed incrementally. For each release the approximate stages of this book are followed: some research, then interface design, coding, a working release and marketing. Check the customer reactions, learn and repeat.

On the lower level, each of the stages is a mini set of iterations in itself, punctuated by testing that informs us whether or not further cycles are required. This holds especially true at the interface and development stages, where a skeleton design or chunk of code can gradually be refined with more detail as it undergoes testing.

If your project has a deadline (and unless you’re working on an informal side project, it will), each high-level iteration should be allotted a specific number of days, so that you can be sure to fit in a number of full iterations, and the learning that comes from them, over the lifetime of the project.

Each iteration should last for a fixed length of time, so that your team can develop a rhythm; you will quickly adapt to the recurring deadlines and become adept at estimating how much functionality can be produced in each.

The exact length of an iteration can range from a week to a month. Your team will need to decide on the best length for them based on a number of factors:

To decide on the deliverables for an iteration, a risk-driven approach7 is superior to choosing the low-hanging, easy features first. When taking this approach, you should first develop the high-priority/high-risk features followed by high-priority/low-risk and, finally, low-priority/low-risk. Low-priority/high-risk features should be avoided altogether until the app is a proven success.

High-risk features can be identified by:

Summary

Plan how your team will develop the app and interact with one another most efficiently, and with the minimum overhead.

From this guide to bare-bones project management, you will have learned:

Web App Success book coverAlso available to buy in a beautiful limited edition paperback and eBook.

This work is licensed under a Creative Commons Attribution 4.0 International License.