10 Tips for Keeping Momentum on Web Projects

Tricks for avoiding stagnation and block points on a web project.

There are many hidden perils lurking in the midst of a web project. So many little devils which conspire against you delivering on time. The nature of a project is that it is a unique undertaking, so unless you can see into the future, chances are there will be hiccups along the way.

If we know there is trouble on the horizon, then we can be prepared. The idea isn't just to have a plan ready for dealing with what maladies may befall your project, but also to use strategies to nip things in the bud before they become a problem.

To that end, I present 10 techniques I use to keep things moving along smoothly on a project. Some of these may seem counter-intuitive at first, so you will have to use your best judgment about what approaches you feel comfortable using.

Before I get into the meat of the article, I should say I'm not covering obvious things like 'use a project schedule' and 'write a spec' - if you aren't already doing that, then no amount of clever tricks will save you.

1. Get the ball rolling early on things involving third parties - a good example is live hosting, you can get seriously bogged down if you leave this until just prior to launch. If you don't have full control over the server it makes you heavily reliant on tech support to do things for you. Another example is e-commerce gateway integration. Do you really want to wait until the last minute to find out if your code is talking to the gateway provider's server properly?

2. Have settings accessible via the CMS - I've found it's preferable to have settings adjustable via the CMS rather than have them in code or in a string table. Options like Google Analytics script code could be placed inside a System Settings or Website Configuration page. Doing this lets non-technical people deal with last minute changes.

3. When there's two ways to code a simple feature, code them both rather than wait for approval - if the features each take only 15 minutes to implement, just code them both and enable one. You have a 50/50 chance of getting it right. If the client decides they'd rather have it the other way around, you switch on the alternate option (preferably via a setting in the CMS). The amount of effort you would expend going back and forth to get a concrete decision from the client is probably going to exceed the 15 minutes it would take to just code the alternate feature.

4. Put in the wrong content - this may sound counter-intuitive and you'd expect it to lead to an unhappy customer every time (but it doesn't, most of the time). This is only for preview/staging versions of the client's project, not their live site. If the client hasn't made content available to you, then use the closest match. Something off their old website perhaps, or workable place-holder text. This does one of two things; the client may say "hey, that's the wrong text", to which you reply "OK, can you give me the correct text please?", or it gets them started by providing a basis to work from (as opposed to starting from scratch).

5. Have a change request budget - this concept is straight out of PRINCE2 methodology. It basically says when you make a fee proposal/tender, include a chunk of budget for unexpected features. So for an eighty hour project, I would have between 5-10 hours of change request budget. The good thing about this is when the client asks for something off-spec, you don't have to wait for approval or try and convince them to pay for it (they already have). It can also help cut down on admin tasks since you don't have to track the item for inclusion in a future invoice.

6. Get clients thinking about what they hadn't thought about, early - a good example of this would be a social media strategy utilising Facebook (assuming it's appropriate for the business). A client may not have thought about Facebook, bringing it up early may have them saying "hey, I hadn't thought of that". That gives you time to provide them with some advice or reading material. Leaving it to the last minute may throw them off, they may even decide to delay launch to consider social media options.

7. Don't just offer options, offer a recommendation - if you talk to a client about a feature where there's two or more paths to choose from, first describe the available options, then the pros and cons for each, and finally make a recommendation on what's most suitable and why. This helps clients who are cautious of making a decision because they don't understand the technology at play. An example would be if a client asked whether its better to integrate a blog into their website or use a well-established one like Blogger.

8. Use a bug tracking system - scope creep can seriously side-track a project, potentially delaying the original launch date considerably. An issue management system lets you deal with off-spec features in a controlled way. If a client asks for a feature and you say no, that's just bad customer service. If you say yes to everything, you'll be coding forever. Instead, if you say "yes, but its been flagged for post launch implementation", you should be able to segment off features for future coding. Unfortunately this doesn't always work, sometimes clients are adamant that a feature needs to be included immediately.

9. Start early on tasks which require client approval - an example of this would be a storyboard for a Flash animation. The client may need a few days to review the document. Connected to this tip is starting early on things which only the client can do. A good example would be applying for an Internet merchant account. The bank will most likely only deal directly with the client due to security considerations.

10. Begin some work before the project deposit arrives - if you're fairly certain the project is going to proceed, do a couple of hours work even before the deposit has arrived. This would be stuff like preparing the project folder, checking that the domain delegation details the client has provided actually work, minor things (but no coding). This gives you a head-start on the project, its creating momentum from the get-go.



Keeping momentum on a project isn't just about following documented procedures. The role of creativity and a willingness to take risks shouldn't be underestimated. Novel solutions which produce results are either praised or go unnoticed, whilst failures may attract negative feedback. The trick is for your successes to significantly outweigh your failures.

Subscribe to RSS Feed.

Making Customers Part of the Development Process

Helping customers understand and get involved with their software project.

The importance of talking to customers about how you will be building their software shouldn’t be underestimated. If you wait until the project is under way to begin managing a customer’s expectations, you'll find it’s too late; expectations have already been set (not necessarily in a good way either).

You can generally assume that in a client's mind, the methodology you use is unimportant minutiae, they are not interested in the nuts and bolts of the process. They only care that the project gets done. This is not to say that the SDLC approach used is trivial; some clients are more suited to an Agile approach whilst others will be happier with classic waterfall. In the case of B2B, where a client may have a technical stake-holder directly involved with the project, keep in mind that there’s no point being ‘agile’ if your client doesn't buy into this too.

Whether developers use Agile or waterfall model is beside the point from a client’s perspective, these are purely internal processes. The only time a client needs to know about the process is at their interaction points. This is like encapsulation in object oriented programming; all a coder needs to know is what the interface looks like and how to interact with it. The inner workings of the function are not his concern.

The key to involving clients with the development process is to only discuss processes which involve them directly. Clients need to know ahead of time what they're getting into and what to expect. Surprising a client with new information half-way through a project often sounds like an excuse. Some development houses use a 'client education pack'. I believe this is a good idea as long as a project manager walks the client through it either in person or over the phone. Assuming a client will want to read a 20 page process manual you send them is just wishful thinking. The client needs to be part of the development process at any point where their input is required. Examples of this would be: meeting with you to describe what the software is meant to do, providing content for their website, approvals (e.g. design sign-off, UAT, etc).

Arguably the most important point to bring up with a client is the effect of adding features to a project already under way (i.e. ‘scope creep’). There's more to this than just saying "if its not in the spec, it will cost extra". There are implications relating to delivery date and more subtle dangers like new features breaking previously working ones. You may have techniques for dealing with these issues such as incorporating a change request budget into the fee proposal or requiring that non-critical features be implemented after initial release.

Another important topic is the interconnected nature of features. Functional dependencies aren’t just confined to the realm of coding, they may extend to tasks requiring a client’s involvement. For instance; a client may not know that credit card transactions can’t be processed on their ecommerce-enabled website until they get an Internet Merchant Account and sign-up with a credit card clearing service.

It’s unrealistic to think business interactions will go smoothly 100% of the time with all customers. That would be like thinking you can please everyone; you can't. This brings up the subject of choosing your clients, or even dropping troublesome ones. Dropping a client would seem counter-intuitive, after all, a business is there to make money, so turning away a paying customer seems kind of crazy.

The reality is that on occasion you will encounter clients who are inflexible or uncompromising. The author Stephen Covey perceptively described the outcomes of interpersonal conflict in his famous book Seven Habits of Highly Effective People. They generally follow this structure: win/win, win/lose, or no deal. In terms of conflict with a client, the win/lose situation would be: 1) developer insists on following their internal process but angers the client (win/lose), 2) developer compromises their process to keep the client happy, but delivers a shoddy product (lose/win), 3) the developer drops the client (no deal). Ideally you would go for win/win situations as much as possible, where both parties get what they want without taking away from the other. A win/win solution is nearly always possible if both parties sincerely commit to working on a solution until an amicable outcome is achieved.

It's important to keep the big picture in mind, if it’s only a trivial point, it’s best to let it slide. For example; a client may insist on red flashing text on their homepage. In such a case all that needs to be said is: "this is a usability concern, I can still change it for you if you like but it will hurt the quality of your website."



At the end of the day it's not the responsibility of the client to understand software development, or anything else for that matter. Their primary responsibility is ensuring that enough budget is available to bring the product to fruition. The technology supplier’s part is to deliver on what’s been promised. Using the hottest development methodology doesn't mean anything if you’re losing business or ruffling your client's feathers. Software development is a service industry; clients aren't concerned with how teams or projects are managed to an intricate level, they care about what they've paid for: results.

Subscribe to RSS Feed.

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.



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.

Subscribe to RSS Feed.

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:



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.

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

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).



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.

Subscribe to RSS Feed.

What Does an IT Project Manager Do? - Part I

A description of the responsibilities of a typical project manager in the IT industry

This article is split into two parts due to its length. Part one starts with an introduction which describes the role a project manager plays during software development.

If you looked at the most prominent job searching website in your region you would find that different industries mean different things when they use the word project manager. For our purposes, we are going to talk about a typical project manager within the software development industry. By no means is this an exhaustive treatment of their duties and chances are good that no single person in a company would undertake all the tasks described here.

Before we can say what a project manager does, we should first take some time to define what a project actually is. We know that a project is often a novel undertaking, an attempt to create or achieve something which hasn’t been done before (hence why projects are inherently risky). The other identifying features of a project include; they have a deadline, a set budget, and a beginning and end point.

A project can be broken into a number of components; design, programming, project management, quality control, etc. These are just the titles I use, but they do have direct parallels with traditional waterfall model stages (e.g. programming = implementation, quality control = testing, etc). For simplicity, I usually roll requirements gathering and system analysis into the project management component. I tend to refer to components rather then phases or stages. The reason for this is because it’s limiting to try and force a software development project into a series of linear steps. It just doesn’t turn out that way because there is so much iteration and overlap between stages (e.g. project management is a process that occurs the whole way through a project).

To get a project done you obviously need people with specialized skills, these people are often geographically distributed, whether that’s down the hall from each other, or on another continent. The chances of these people coming together as an organized group is pretty slim. And this is where a project manager comes onto the scene.

So then, what is a project manager? You could say they are the glue that binds things together, they don’t actually do the work, but rather help others do it. They are at the helm of a ship, steering it via a predefined route to a particular destination, with course corrections to be expected along the way.

Sure, this is a somewhat simplistic definition, but we are just getting started. If we were to expand on our description, we could also say a project manager is meant to make the unpredictable predictable, ensure resources are used wisely, and handle problems which seem to appear out of nowhere.

The purpose of software is to solve a business problem or exploit an opportunity. Based on this goal, a project manager is likely to assist in figuring out what features the application should have. Before a project begins in earnest, they also have to determined if the project is technically feasible and not prohibitively expensive.



A project manager should know about the people on his team and what their capabilities are. Who’s good at JavaScript? Who knows about video encoding technology? Who’s the best person to research a shopping cart component? This isn’t just a matter of utilizing peoples’ strengths, but also making them happy by allowing them to do what they like. For example, creating a timesheet template may be hell for one person, but sheer joy for another.

Setting up the ground rules for communication is also the domain of a project manager; is the team going to have regular meetings or impromptu chats? Are we using MSN or Skype to talk to our overseas contractors? How often will programmers report their progress so the project schedule can be kept up-to-date?

Scheduling is arguably the most important task a project manager undertakes. He needs to know if there are any dependencies (e.g. an Internet Merchant Account has to be setup before credit card payments can be accepted on a website). They need to be aware of any external factors affecting the project’s deadline (e.g. the client wants to show off the software at a trade-show in two months). Regardless of what tool is used, the project schedule needs to at least say what is going to be done by when, how much time tasks will take, and who is doing what.

Resource allocation is a juggling act project managers need to excel at. Which programmer should work on what? When can they work on the next project? How much time should be set aside for bug fixing? Often companies will have multiple projects running simultaneously. This makes it quite tricky to get the most out of the limited resources available.

Making sure that the software solution delivered to the client is bug free and in fact what they asked for is another major responsibility of a project manager. This could involve writing tests plans, creating quality assurance standards, defining acceptance criteria, and organizing independent testers to carry out testing. A project manager is often the first person a client contacts when they find a bug in their software, ideally the client should be logging defects in a bug tracking system. The project manager then assigns the logged bugs to the most appropriate programmer for resolution.

A project manager is responsible for risk management. They need to be aware of what can go wrong and how likely it is to occur. Finding out about it after it happens is too late, a good project manager will spot a problem coming from a mile away and have a plan ready for dealing with it.

A project manager might need to consider external factors like: competition, industry standards, future market forces, environmental issues, social and political impact. It’s quite rare for a project manager to be called upon to analyze and document these forces (e.g. they may do this as part of an e-strategy). Most of the time this information would be in the client’s business plan.

At smaller companies it’s not unusual for a project manager to wear a number of different hats. For instance, they will commonly double as a business analyst, responsible for writing functional specifications, creating wireframes, making recommendations on technology, and deciding what development tools to use. They may even have minor administrative duties like preparing invoices for clients.

Read part two of this article... (not available yet)

Rescuing a Hopelessly Derailed Project

Perspectives on the maladies that befall an overdue project.

A sobering reality of the software development industry is that projects sometimes run late; most of the time it’s not the end of the world, although this view is not held by all (the word ‘late’ seems to be a very dirty word in the business world).

In the grand scheme of things, a project arriving one week late generally has no significant impact. Of course there are exceptions, for instance; a project may need to be delivered to coincide with a client’s attendance at a tradeshow. The kind of late project I want to deconstruct in this article is the hopelessly derailed type, generally running months behind schedule, with an irate customer banging down at door.

The causes of a hopelessly derailed project are many and varied, but the particular focus of this article is the inherited late project; this is where a newly appointed manager must pick up the pieces of a disastrously run project. Thrust into the midst of customers screaming for blood and management demanding results.

If you are a project manager finding yourself in such a situation, first and foremost you must be resolved that you may fail despite your best efforts. As the saying goes; “fortune favors the bold”, so if you can’t accept the risk, then you should not accept the challenge. This also extends to the possibility of being made a scapegoat. I don’t believe there is a level of intrigue functioning in an office where upper management ‘sets people up’ for a fall, it’s just businesses don’t like losing money. In a corporate environment, taking on greater responsibility often comes with increased salary, but if things don’t work out, your head is for the block.

In order to steer a lost project back to safe waters, a view for the long haul needs to be adopted. This seems logical since no one would be worried if only a small amount of work was required to fix a troubled project. On one occasion I worked at a client’s office for 8 months straight in order to launch their ERP application. I also have heard of instances where developers toiled for almost a year to save a late project.

Assuming you're OK with the risk of things still going pear-shaped in spite of whatever efforts are brought to bare on a late project, the following course of action is what I would prescribe (note: not all these strategies are appropriate to all projects);

Use a bug tracking system - installing and using a bug tracking system is going to be an excellent start. It will allow you to regain a semblance of control and take stock of the situation. It’s unrealistic to think a complex system can be understood immediately as a whole, so 'chunking' it often helps. A bug tracking system allows you to compartmentalize problems. Once an inventory is taken of all existing issues, distribution of tasks amongst technical team members becomes a breeze.

Realize the political obstacles are greater then the technical - on a late project there are both technical and political challenges to be overcome. The technical issues generally aren’t as bad as they may first appear, especially if a senior programmer is on hand or the project manager has a technical background. The political difficulties are trickier because they are less obvious then an error on a particular screen. It’s like being at the helm of a ship that’s gone off-course, lost in the middle of the Bermuda triangle. The biggest challenge is often re-establishing client confidence in the project (e.g. client: "these cow-boys don’t know what they are doing!", "they promised me this and didn’t deliver", "I have no confidence in these guys any more.").

Stem the tide of negative sentiment - apologizing to the customer for the poorly managed project is a good start, a bitter pill to swallow but necessary for re-establishing trust. Stating to the customer in concrete terms what is being done to correct the problems on the project is also helpful. For example, something along these lines: "I’m sorry about the delay on your project, I’m working to get it back on track now. I’ve looked at the project history, and personally, I would be angry too if I was paying good money for this system. The first thing I’m going to fix is...". Making such a statement means there’s no turning back as responsibility has been taken for the project; its all or nothing now.

Feature freeze - a common and sensible strategy is to stop adding new features. In reality, this may be easier said then done. It’s possible that agreeing to some new features requested by a client can help re-establish report, a demonstration of your willingness to listen. From a technical stand-point, adding features to an already late project doesn’t make sense, but from a political perspective, it may be a step in the right direction.

Understand the business domain - reading through any requirements documents on hand is going to be vital. Arriving late on a project is a massive disadvantage because it’s hard to know what was originally discussed. As the saying goes; ‘the devil is in the detail’. This is exactly what sunk me on a late project I was meant to salvage. Everyone was on edge, and I missed a minor requirement. At the time, it wasn’t a big deal and could of been corrected easily, but politically speaking, it was the straw that broke the camels back. One strategy which may help is to work from the client’s office for a few weeks, at least until some semblance of stability returns to the project.

Consider adding some new features - a late project isn’t exempt from this old business maxim ‘time is money’. The client has paid for something which isn’t right or has not been delivered on time. Your company has expended resources working on the project, possibly having used up all the available budget. Continuing work on the project could mean your company is losing money. This is where allowing the late addition of new features can make sense. People will say not to add features to an overdue application, that stabilizing the project is the number one priority, but adding new features can be a politically prudent maneuver. Senior management will likely be pleased that new money is coming in for billable off-spec work, but programmers probably wont share this enthusiasm.



Overtime wont fix everything - I’d recommend against project managers or coders working ridiculously long hours, but an additional couple of hours each day can make a positive impact on a late project. If people normally leave the office at 5pm, departing at 6.30pm-7pm instead is reasonable. People can consistently maintain an hour or two of extra work per day for many weeks without sacrificing the quality of their work or their sanity. Working until 9pm or 10pm every night and on weekends will result in burn-out within a few weeks. After that point, extra time on a project is doing more harm then good. In the unlikely event that senior management takes issue with this point, a decision needs to be made; do as they ask (i.e. work more hours), or say something along these lines; "I’ve already committed a few extra hours each day to work on this project. I’m here for the long haul and I’m going to get this project done. But I’ve reached the limit of how much extra time I’m willing to put in. There are other commitments outside of work I need to keep too." Unfortunately, taking such a stand in some organisations can have negative consequences. By no means am I against working hard for a worthy goal, I am merely saying the effort needs to be weighed up against what you are going to be sacrificing (e.g. health, family, etc).

Get movement on the project - I have come across suggestions that when first arriving on a late project, the best thing to do is “stop and write a spec” or “stop and do this or that...”, I believe this is unrealistic. The project is already stagnating, the last thing senior management or the client want to see is a complete halt, they want to see progress! I have been in a situation where I’ve told a client “we need to stop coding for a week or two so I can write a proper test plan. Otherwise the bugs will just keep coming.” It’s not that the client didn’t understand the importance of this, it was more an issue of cost; who was going to pay for this time? The client wasn’t willing to pay for the lull in development, nor was the company developing the software. Needless to say, the bugs did ‘keep coming’. It’s important to get some small wins happening so things can get moving in the right direction again. This could come in many forms; for instance, clearing all currently logged bugs, stabilizing one particular module within the system, etc.

Map-out tasks ahead of time - a project manager needs to work-out what programmers are doing ahead of time, having programmers waiting on a project manager to give them work is tremendously inefficient. For a technically-oriented project manager or senior programmer, this will generally mean they get to do less coding or technical work. The best way to map-out tasks is by maintaining an up-to-date schedule which lists pending tasks and who’s responsible for them. Programmers should always know what they’re working on after they finish their current task. There should rarely be a time when they ask "what do I work on next?", they should already know.

Build-in recovery tools - sometimes to achieve a goal or solve a problem, an indirect route is required. For example; it may take 12 hours to track down and fix a particularly troublesome bug. Instead of doing this, it may take only 2 hours to code in a corrective utility which solves the problem for the time-being (yes, this is sort of a ‘hack’). Time and momentum are of the essence on a late project, and unfortunately bandaid fixes sometimes make the most business sense, especially when software has recurring problems which are hard to pin-down.

Be observant of the client’s mood - it’s important to demonstrate you are on the client's side. For example, the client may say "this product is unacceptable", you could respond with "I agree, I wouldn’t be impressed If I were in your position either. All I can tell you is I’m focusing on it now and wont rest until you’re happy". When report is re-established with a client, they may even help shield you from pressure emanating from other stake-holders on the project.

Lead by example - programmers have no reason to become emotionally invested in helping to correct a hopelessly late project, and why should they, it’s management that got them into this mess after all. But programmers may care if it becomes about comradery or delivery of a product they can be proud of. For instance; a project manager may tell the programmers "I’m staying back a few extra hours to work on the project. I’d appreciate your help if you’re willing to give up your time." Or "I know its not our mess, but we're going to clean it up anyway. I want to get our customer the best good quality software we can". Emotive rhetoric is useless if it's not from the heart, people can spot a phony a mile away and wont appreciate being manipulated.

Many suggestions made by other project managers on how to fix an ailing project assume a fairly high degree of power to affect change (e.g. “say no to new features” or “stop the project to restart it properly”). In reality, chances are the project manager is joining the late project already hamstrung. If it’s a senior programmer that’s been tasked with correcting a failing project, they will traditionally have much less power to affect change then a true manager. This doesn’t mean “give up, don’t try”, it just means a lot more creativity and soft skills will be required (i.e. people skills).

I’ve also come across people who say its better to bail on the project and ‘run for the hills’. I have had experiences where it was possible to fix a hopelessly derailed project, and some which could not be salvaged to everyone’s satisfaction. It’s really a personal choice whether to take up the challenge or not.

Management Styles in Web Development

How operations management affects project management in a web development environment

“Fostering an atmosphere that doesn't allow for error simply makes people defensive. They don't try things that may turn out badly."
- Tom Demarco, Peopleware

One of the best teachers I know once let a martial arts student punch a wooden board when he knew it wasn’t going to break (due to incorrect technique). After the student’s failed attempt, he said to the group “I could tell it wasn’t going to break, but who am I to stand in the way of your dreams and goals?”

It’s happened a number of times now that I have arrived at a company and heard statements like “run projects how you think best. After all, we hired you for your expertise and experience.” These bold proclamations inevitably give way to operational management’s desire to change things for the better good (i.e. over-ride some of my decisions).

Perhaps this happens because project management looks like a logical pre-defined process, much like operational management. However, the whole point of a project is to create something novel and never before seen, thus introducing a large element of the unknown to the undertaking. This is one of the reasons why risk analysis is such a major part of formalized project management methodologies.

Passion or concern can often lead operational management to actions which actually stifle a project. Much like a mother, at some point they have to ‘cut the apron strings’ and allow their child to make some mistakes for themselves.

It’s like watching a child banging their toy against a wall, do you say “that’s going to break if you keep doing that” or do you take the toy and save it from certain annihilation, potentially robbing them of a valuable lesson on taking care of their property? On the other hand, some lessons can’t be learnt the hard way, for example; crossing the road without looking both ways.

The question then becomes, do you stand by and watch someone make a mistake? I would hazard that this would often be the motivation of upper management, that to them it looks like you are about to make a mistake which could cost the company money or damage client relations, so isn’t it logical to intervene before its too late?

I’m fairly sure no managing director wakes up in the morning and thinks to themselves “hmm, how can I make my project manager’s life difficult today?” I should say that I don’t intend for this article to be a denigration of past employers. Operations managers generally don’t acquire their position without being highly intelligent and capable. But I have seen the phenomena Joel Spolsky calls Command and Conquer Management. This is where the person least qualified to make a decision is doing just that.

From the companies I have worked at so far, I have seen three distinct approaches when it comes to operational management dabbling in project management. One type would commonly interject if they felt they had a better way to do things (with changes I could not veto), another would occasionally come to the rescue if things weren’t going as planned (again, with me having no veto power), and probably the most interesting one has been a boss who only occasionally intervened, but still allowed me to have final say.



Personally, I wouldn’t want to work in an environment where people didn’t say something if they felt you were about to make a serious error with your work. But that is obviously part of what team is about. People need to be able to ask questions and give suggestions. But they should also be given the option to reject a suggestion without ego coming into it.

project management isn’t an easy discipline, hence why not everyone does it. As mentioned earlier, the reason for this is because a significant portion of a project is unique. Getting good at tackling the unique aspect of projects only comes with experience, and experience comes in two flavors: success and failure. Unfortunately, it’s hard for some people to accept the unpredictable nature of software development because mistakes can be expensive.

Another interesting ingredient being added to this dynamic is the increasing uptake of industry standard project methodologies such as Britain’s PRINCE2. Although this is definitely a good direction for the software industry, it does pose a potential hurdle.

PRINCE2 is squarely aimed at project managers, there’s no doubt about it. The problem lies in the fact that non-project managers within the team also need to understand the methodology for it to work well. I believe it’s possible for a project manager to teach the basics of PRINCE2 to subordinates such as team managers, programmers, designers, etc. (just enough for them to get by). But would this work upwards, with corporate management?