Under-priced projects (tight budget) - what are the characteristics?

Question

I'm trying to determine some of the markers that indicate a project of limited resources.

In my experience a project becomes a ‘limited resources’ project because someone was desperate to sell a solution to a client. The results is a tight budget, features are culled and SDLC processes are cut to a minimum. These short-cuts are taken so the company has some chance of making a profit or even breaking even.

This is a list of things which I have seen go hand-in-hand with a project of limited resources:

• Bare minimum amount of time allotted to QA
• Strict bureaucratic process for off-spec work
• Change request budget may be small or non-existent
• Formalised processes get dropped in favour of using time for development
• No time available for value-add QA like content checking (e.g. grammar or spelling errors in text).
• Can’t do any content management or data entry for client
• Have to go for ‘good enough’ coding solutions
• No time allowance for hallway usability testing.
• no budget for writing user documentation or manuals.
• Generally no time for technology research before coding
• No time to produce a risk analysis document
• A production check-list may be used instead of a project schedule.
• The is no time for a programmer to fill their ‘actual’ times vs. estimated times in the project schedule.
• Progress updates given to clients may be less frequent or very basic
• Less time is available to spend on understanding the clients business domain
• Programmers may have to work unpaid overtime.
• No time allotted for a project post-mortem

What other sure signs are there for a limited resources project?

===

EDIT

i will try clear up some of the confusion with an example. this is what i mean: the client is given a proposal/quote saying their project will cost $20k. the client then comes back and says "sorry, my budget is $16k maximum". the boss says "make the proposal $16k - we want this work".

so, effectively, you have to do a project with less budget then it should have. there are boundaries where it becomes ridiculous - if the client was to say "my budget is $4k" then you couldnt possibly do it.

and yes, sometimes a tight budget can become so silly that it was a bad business decision to accept the project in the first place (i.e. doomed project).

i understand that there is no such thing as a project with unlimited budget. often business people make the decision whether a project should be undertaken (a business person often isnt a project manager).

Answer 1

using the information you guys so kindly contributed i was able to pull it all together and write an article

ill put a link here in case someone in the future is looking for help on the topic:

Surviving An Under-resourced Project

--LM

Answer 2

What you are talking about is not a 'limited resources' project, but instead a rushed and unplanned project.

A few items in your list I take issue with:

• Strict bureaucratic process for off-spec work
• Change request budget may be small or non-existent

Actually, these should be the norm for most projects. Who's requesting and paying for the changes, you or the client?

• Can’t do any content management or data entry for client
• No budget for writing user documentation or manuals.

If that's not part of the contract, why are you doing it?

• Have to go for ‘good enough’ coding solutions

At some point, you have to stop at 'good enough', or else you are going to be polishing from now until the end of time.

Something I would add to your list are:

• Office supplies become scarce or go under lock and key.
• Corporate supplied food/beverages disappear
• Down time disappears. 100% of your time on your time sheet must be dedicated to project work.
• The printer/photocopier is running full-bore printing other staff member's resumes.
• The Boss' door is shut for 90% of the day.

Answer 3

"Under-priced projects"

If I understand correctly what you mean, you really are talking about projects where the resources available to the project are not appropriate to achieve the results that were promised to the client.

I can think of four ways for this situation to arise:

1. Wrong estimates when preparing the project plan
2. Requirements creep
3. Reducing the project budget without reducing the project scope
4. Inadequate resources (staff skills, computer resources, etc.) for the project scope

When people in the project become aware of the situation, they really have two options: cut costs or cut scope. Cutting the scope can be a hard sell and may endanger the project viability, so most of the time people opt for cutting custs, especially since cost can be cut in many ways without atracting the attention from the higher echelons:

• Unpaid overtime
• Reducing quality
• Eliminating documentation

and so forth.

In fact, you may even look good as a project manager when you start cutting costs, since cost containment is one of the project manager's responsibilities! I assume that what you want is to find ways to diagnose an under-funded project. I think that instead of developing an extensive list of symptoms, I would strive to identify a general condition.

In my opinion, there is a general condition that allows to pinpoint an under-funded project. For most projects, staff is the biggest cost - or at least the second biggest cost that can be managed by the project manager. Whenever you find an experienced manager taking measures to reduce staff costs and those measures were not part of the original plan, then you can be sure you have an under-funded project.

Regards,

Answer 4

• Continuous occurences of new, forgotten features, assumed as "obvious" and "implicit" by the user, never stated in the requirements, leading to discussion Bug vs. Change Request.
• Waterfall model adopted instead of an iterative approach.
• Customer protesting on the costs of fixing, saying something like: "If you have bugs, it is because you didn't do your job right", not accepting the tripple constraint effects on quality when cutting time/budget.
• Pressure for lower prices for maintenance and support activities after project deployment in production.
• Pressure for adopting a fixed-price project (outsourcing) to transfer financial risk together with timeline risk.

Answer 5

Outdated or obviously beta documentation which doesn't jive with whatever release of the product on site, or documentation which looks like it's been down through several generations of Xerox copies.

No onsite installation or support. Depending on the size of the system being implemented, a company in good shape might send one or more of their developers to oversee the implementation, whereas a company that's tight might offer phone or email support only in a more "fire and forget" approach.

Answer 6

Quite frankly, I've never heard of a project that had unlimited resources. Even the government will put the brakes on something after a while.

So, from a pure logic perspective, all projects have limited resources.

Answer 7

Limited resources? All projects that I know of have limited resources:

• time
• developers
• budget