About PM4Web

The PM4Web blog was born as an outlet to return knowledge back to the web development community. My goal is to share my experiences as a project manager from over the years in a manner which helps you succeed with your own projects.

22 June, 2009

Surviving An Under-resourced Project

How to cut development time on web projects that have a tight budget.

In the competitive world of web development, it's not unusual to be handed a project where the resources available are not adequate enough to achieve the results expected by the client.

A common reason why an under-priced project has been approved in the first place is because someone was desperate to sell a solution to the client. The result is a tight budget where features must be culled and SDLC processes streamlined.

For the sake of illustration, let’s say a client is given a proposal stating that their project will cost $20,000 to build. The client then comes back saying "that’s too much, I have a budget of $16,000 at most." It's not unusual for the person who wrote the proposal to be told "adjust the quote so it comes out to $16,000. We want this work."

We now have a situation where the project has to be undertaken with less money than is ideal. A tight budget isn’t necessarily a bad thing, but sometimes a project can be so drastically under-priced that it is plainly a bad business decision to accept the project in the first place (i.e. a doomed project). There are boundaries where it just becomes ridiculous; if the client were to say "my budget is $4,000", then the company couldn’t possibly take on the project.

Is there any difference in managing a project with a tight budget vs. a amply funded one? The answer is yes. In an under-resourced project all tasks which aren’t absolutely necessary are jettisoned. A big reason for this is so the company has some chance of making a profit or breaking even. Because of these cut-backs, an under-resourced project is often in danger of suffering serious quality consequences.

Since there is no such thing as a project with unlimited resources , the question then becomes a matter of what are the indicators of an under-resourced project. Let’s take a look at some typical tell-tale signs:

  • Bare minimum amount of time allotted to QA
  • Overly bureaucratic process for change requests and off-spec work
  • Change request budget may be small or non-existent
  • Formalized processes get dropped to use time for development
  • No time for value-add QA like grammar or spell checking
  • No allowance for hallway usability testing
  • No on-site installation or support (phone or email support only)
  • No budget for writing user documentation
  • No face-to-face user training
  • Documentation which is out-dated
  • No technology research ('good enough' coding will have to do)
  • No time to produce a risk analysis document
  • Poor or barely existent project schedule
  • Coders don't track their actual time taken for tasks in the schedule
  • Company perks disappear (e.g. food, beverages, etc)
  • No down time - time sheets reflect 100% allocation to project work
  • Progress updates for clients become infrequent and rudimentary
  • Less time is spent understanding the business domain
  • Programmer have to work unpaid overtime
  • A project post-mortem isn't conducted (i.e. lessons learned )

You may notice many of the compromises are quite minor. And there is a reason for this. Under-resourced projects exists at the border line between a project not going ahead at all, and one just barely being ratified. If resources and processes were cut to an extreme level, then the project would be destined to fail no matter what (e.g. a project with no functional spec or project schedule isn’t under-resourced, it’s just plain old crazy).

For project managers finding themselves at the helm of an under-resourced project, there are a few strategies which can be used to not only deliver the project, but also maintain an acceptable level of quality:

Minimize iterations - the more it goes back to the client for feedback, the longer it takes. I know this flies in the face of modern Agile practices, but what I’m saying is to limit the feedback cycle, not abolish it. What does this mean in practical terms? It equates to establishing ground rules with the client early on (e.g. only allowing three iterations to get the wireframes correct). Could this be construed as under-servicing the client, perhaps. But it may also force the client to be decisive rather than relying on iterations.

Use informal sign-offs - use email as much as possible as a sign-off medium. For example; you may send the client a JPEG of their website design and ask them to reply with something along these lines: "I approve the design". It’s a simple time saving strategy because it always takes longer to get a physical signature from a client. Getting informal sign-offs also reduces iterations since the client knows they are officially locking in a decision.

Maintain a production checklist - on a smaller project involving just one or two people, time can be saved by using a production checklist rather than a full-fledged project schedule. A production checklist is just two items in an excel sheet; task and percentage complete. It says nothing about estimated hours. Couldn’t you just drop the production checklist completely and save even more time? Sure you could, but then the chances of missing something becomes a real danger. Back-tracking to include a forgotten task could take more time then the investment in making the production checklist in the first place.

Use passive reporting - instead of chasing programmers to ask where they're at with their tasks, get them to come to you. This can be achieved by asking team members to update their areas in the online project schedule twice a week. Another way is to get team members to email you when they have a deliverable to report (e.g. "the SSL certificate has been installed. I have a confirmation email from the hosting provider").

Propose staged development - if a client has a big project but not enough money to get it done, then suggest they break up the project into a number of stages. The initial or 'core' stage would include the most vital features which they simply couldn’t do without. Later stages would bring in the nice-to-haves and value-add features.

Use a bug tracking system - generally speaking, you should be using a bug tracking system anyway. But it becomes particularly important in under-resourced projects since all time expenditure needs to be allocated with great precision (i.e. there is little room for error).

Use mini-specs - once coding begins, chances are good new features will be requested at intermittent points during development. Rather than adding features during the main development cycle, gather them together into a mini-spec. The items in the mini-spec would be implemented after the originally scoped product is delivered (possibly taking it to version 1.1). By not adding features in drips and drabs, you are optimizing integration.

Do 'feature triage' - be harsh on what features really need to be included in the initial release of the product. It may be painful for a client to accept that they can’t have the world on a shoe-string budget, but something's got to give.

Trim unnecessary tasks - instead of doing two rounds of system testing, do one. Instead of allowing for two on-site visits to conduct user acceptance testing, do one visit and the rest via phone. Do you really need to spend an hour worth of travel for another face-to-face meeting with the client or will a phone call do? If you are observant, creative, and ruthless, you will see many opportunities where time can be trimmed. Of course, hacking away too much will mar the product’s quality and just require time be re-invested for fixes.

Dilbert - estimating project cost

A question which surely beckons attention is what impact a tight budget has on product quality. A client isn't going to accept an excessively buggy product in either a well funded project nor one with tight resources.

You can still attain a level of quality closely approaching a well-funded project. What it comes down to is things like how polished the system looks (e.g. amateurish icons vs. professionally designed ones). There could also be less relationship building with the client since there isn’t as much time for face-to-face meetings. A reduced QA cycle may uncover fewer errors, so the system gets launched with dormant bugs that surface later down the track. Successfully delivering a under-resourced project isn’t impossible, the trick is knowing what to trim and what to keep.

Join RSS FeedSubscribe to RSS Feed.

07 June, 2009

From Requirements to Production

Reviewing the process which takes place from requirements gathering all the way up to production.

Every small web development agency is unique in some way, this is usually what gives them some kind of competitive advantage. Part of that uniqueness is the process they use to convert what a client wants into reality (e.g. a website). This article discusses that process in a big picture kind way, the main focus is on roles - or who does what.

I've seen a few versions of this process at different companies I've worked at, but they mostly involve the same players each time (e.g. a sales rep, a project manager, etc).

Most small web agencies could say their work is divided into two arenas: small web projects and custom development. Small web projects would be basic websites such a business web presence. A custom software build covers all other scenarios (e.g. where a lot of code is written to account for the client’s unique business rules).

The processes described in this article are most relevant to the small web projects stream, mainly because this kind of work is generally the same thing over and over again (e.g. client: "I would like an about us page, and a contact page...").

The players – before we begin the discussion in earnest, we should establish the roles in the process, or 'who does what'. Job responsibilities often go hand-in-hand with a job title, but not always. So, lets introduce the players:

The Players

In the first approach, which I like to call the split-role approach, the process unfolds as follows:

  1. BDM sells web solution to client.

  2. Business Analyst contacts the client to take-down their requirements (and then hands that over to the Project Manager)

  3. The Project Manager organises production resources.

Split-role approach

The alternative method is called the dual-role approach, which looks like this:

  1. BDM sells web solution to client.

  2. BDM gathers requirements from client and hands it over to the Project Manager.

  3. PM/BA reviews requirements (and often asks BDM to gather a few more details).

  4. PM organises resources and ensures delivery

Dual-role approach

I should mention that I specifically haven’t represented the iterative nature of development in either diagram (for the sake of simplifying the diagram).

Each approach has certain strengths and weaknesses. The most obvious difference between the two structures is that the dual-role approach combines the jobs of a Business Analyst and PM into one individual. The benefit of this is it cuts out one communication channel. The downside is it can be hard to find an employee with evenly matched business analysis and project management skills.

The dual-role approach also requires that the BDM have business analyst-like abilities, not as refined as a true business Analyst, but pretty savvy none-the-less. The fact that the BDM is capturing basic requirements takes a load off the PM/BA combined role, allowing them to effectively manage more concurrent projects.

Since the BDM is acting as a watered-down Business Analyst, its likely that the Project Manager/Business Analyst will often need to get clarifications on the requirements which have been gathered. For instance, the BDM may write down: "the client wants to put their products online", to which the PM/BA may say "does the client want to sell their products online, or do they just want an online product catalogue?"

The biggest concern for the BDM/BA combined role is that the skills needed to be a good BDM and a good Business Analyst aren't the same. Most BDMs aren't as structured in their thinking (which is needed to gather solid requirements), but then again most BAs don’t have the soft-skills a BDM generally has.

Pricing considerations - since we are dealing with basic website builds here, it is fine for a BDM to provide a client with a ball-park estimate at the initial client meeting. The final pricing does need to be settled by a proper Business Analyst though, they are the only ones that can cost the project with the least amount of risk.

There is also the issue of up-selling and business re-engineering. On the one-hand, a Business Analyst consulting directly with a client may improve the technology solution by making useful suggestions (split-role approach). The flip side would be a BDM is more likely to get a greater budgetary commitment from the client, due to their selling expertise (the dual-role solution).

Dilbert - Sales Engineer

Personally I prefer the duel-role approach since it reduces the number of communication channels (or 'integration points'). The more communication channels, the greater the risk of losing information or misinterpretations. In addition, small companies generally can't afford to hire specialists (i.e. a specific person for a Business Analyst role, another person for the PM role). I can however appreciate that the split-role approach offers some degree of scalability since there is more division of labour.

Special thanks to members of the Stack Overflow community for their contributions towards this article.

Join RSS FeedSubscribe to RSS Feed.