Use agile development/design practices instead :) But seriously, the web is a moving target and you can't expect your clients to be able to visualise themselves everything upfront, it's part of the game that you have to change stuff well into development.
Fire the client. Nothing good is going to come from an engagement where the person wants fast and you want correct.
In the classic "good fast cheap -- pick any two" when they pick "fast and cheap" you invite them to pick a different consultant.
I guess a fairly decent solution would be to potentially implement more Agile methodology for clients who feel they want more of a "streamlined" feel to their project. That could make them feel as if things are going by faster and not necessarily being held back by the "bureaucracy" of project management.
Give the client an overview of what actual tasks "Project management" consists of. Ask him which of these should be omitted or assigned less time. Explain the consequences of doing so.
The suggestions I would make would be to
Make sure your clients are clear on your methodology and how time is allocated before the project even begins. Maybe consider a project charter (in a lot of cases I think that is overkill)
Determine what the client's root dissatisfaction is, it is probably not "focusing too much on the project management", it is more likely to be concerns over time frame, or cost. It will be easier to address a specific issue than the broad one they are providing.
It sounds as if your client really wants more visible progress on the project output. If you feel the output of the project will be adversely affected by following your client's suggestions, you need to show him/her the value in those project management tasks. If you can't show value, you should really consider whether you can meet the client half-way. And, if your client wants you to skip things you find valuable, have them sign-off on the risk associated with it.
Project management is important - but it is not 40% of a small web site!
Consider also that lumping QA as a 'project management' task leaves a very...waterfall... impression. The suggestions to use a more Agile approach should be considered very very seriously.
I don't want to come right out and say that you are being too bureaucratic, because:
But offhand I will say that this certainly looks like excessive bureaucratic overhead.
For a small web site (~$3K) using Agile, I would estimate that at most 5%-10% of the budget would be for project-management and -administrative overhead. [Note that QA is built into the Agile process as part of development, not as a separate 'phase'.] I would also expect that half this 5%-10% would be devoted to up-front BA (Business Analysis) to define the scope of the problem, goal of the web site, and major features, and the rest would be incremental as the features were tackled.
EDIT: based on exposition above:
the first section (mockups/design) is critical, and the result of that will likely change the plan for programming. Do the mockups time-boxed and then replan the rest, chunking the deliverables as site features bound to the mockups. Unit test each feature instead of all at once at the end, and include extra time for testing in each feature 'chunk'. Bundle the SEO/analytics/setup into a single "iteration zero" setup revision with a (padded) fixed cost. Keep a checklist (and a baseline disk image if possible) from this to reuse in other projects. So the estimate would look more like:
1. Site Design and Mockups: 30 hours
1.1 Requirements gathering, needs analysis,
Feature identification, user stories: 5 hours
1.2 Initial mockups/design revision: 15 hours
1.3 Second mockups/design revision (optional): 10 hours
2. Site Features (subject to revision): 60 hours
2.1 (iteration zero) configuration and setup
(AURON, Analytics, etc.): 10 hours
2.2 Feature: site structure/template: 10 hours
2.3 Feature: News page: 10 hours
2.4 Feature: Downloads page: 10 hours
2.5 Feature: Clients List page: 10 hours
2.6 Feature: Contact Form: 10 hours
TOTAL: 90 hours @ $50/hour = $4500.00
Notes:
1. second revision of design/mockups only if required
2. additional features beyond those specified above are out of scope
3. site to be developed in single-feature iterations
with sign-off (and payment!) after each
4. half in advance, prorated payment after each feature
iteration completed
5. customer may cancel project after each revision
6. no refunds.
While I've been doing outsourcing jobs I usually had more than 50% of time spent on initial project planning and prototyping, just to have the damn thing right on schedule and within the budget. And my team did deliver on time and within budget.
If customer was not ok with that, then it was better (more efficient and less costly for us) to part with him from the very start.
PS: Project Management as in PMBOK ed 2.
Without knowing you or the client - it's difficult to really answer, but some possibilities:
To me, project management should be like a pencil, it's there when you need it, you don't need to understand how it works and you don't need to think about it. If you keep pushing the beauty of the pencil instead of what the pencil is creating - the pencil becomes a distraction.
What are the client's real needs?
Is the client really saying "two weeks is too long; you're focusing too much time on the project management process"?
Or is the client saying "$3000 is too much; you're focusing too much of my money on the project management process".
Or is the client saying "the app doesn't work correctly; you're focusing too much on the project management process and not enough on the quality"?
If it's not any of these things, and the client gets what they want, when they want it, for what they want to pay, then it's your business how you deliver.
If it is one (or more) of those things, I don't think you can deal with the situation until you know what it is.
[Edit: based on the comment by the poster that he thinks money is the reason...]
Mr. Client, I understand your concerns and I know you want to get all the value you can for the money you're spending on this project. If you like, we can look for ways to reduce the cost of this project. Here are some features we can postpone until a later release, [etc.]
If you don't get any value in the detailed reporting of my development process, I can save a little time by not making a presentable version for you to review. Rest assured, I'll still be doing all the same planning because that is how I insure the project will be completed on-time and on-budget with all the features that you've requested.
Could I get more done by skipping the planning? Absolutely not. In fact, without planning, it would cost you more because I would accomplish less in the same amount of time and the quality would be lower.
--
bmb
Perception is reality in the eyes of the client. Facts don't always seem to be relevant.
Maybe you could look at building in the development / planning costs right into the implementation costs.
What's important for the client to understand is value. I don't want to assume anything, but at the end of all analysis / design, I provide a written feature/tech spec that they agree and sign off on. It might be a simple email, or a document.
We are hired to generate more value than for which we are paid. If we do it, we get more work. If we don't, we move on.
It helps to have clients learn to look at a project in terms of not what it costs, but what it will make them. Some clients focus on saving pennies instead of making dollars. Software is almost always better made with a process than without one. Maybe he would like to do an agile methodology and pay for your time straight to get what he wants, how he wants it?
Focusing every word you write in terms of:
is paramount. It's hard to do that literally for each sentence. I usually start my proposals out with the value of my processes and tools.
The disconnect might be happening because your client is either too busy, or not interested in understanding the details. You have to fill the gap and make them comfortable leaving it with you and that you are making decisions in their best interest -- and not your own.
Building trust takes time and best done as mentioned in one of the posts above - short victories, often towards the final goal. They see results as progress and don't worry about the activity (development/planning) time as much.
Working without a plan is like building a house without a blueprint and only a few rough sketches. How much would you have to re-do things during the construction of such a home?
It is impossible to give a client the best value, without a plan that you create and manage for them, simply doing the work can cost two to three times without a plan. In such a case you can tell them that they can hire you hourly and you'll do whatever, forever.
In seeing your proposal above it might have too much information. Good in some ways, and maybe not since it's causing
I stick to six steps that I cover. The simpler the project is, I just combine them. The more details I have to break out, I will write more in each area. Each area requires a sign off before moving to the next. It's a variant of the waterfall software process. I track each as Being "To Start", "In Progress", or "Completed".
I have modified my project management software (FogBugz) to handle it and it works well. I can run a report and see where any request is at in the following phase.
1) Analysis - "What do we want to do" Both sides must agree on the scope and final results and how they will be measured.
2) Design - "How are we going to do it"
3) Plan - "Who/what will we need to lineup/prepare and when will we do this"
4) Implement - "Do it"
5) Test - "Break it and fix it"
6) Launch - "Soft + Hard Launch"
7) Support - "Training/Documentation, as required"
It's weird. I have done 20-30 page proposals and not gotten the project. I have boiled the same down to 5-7 pages and for a larger project and gotten the work. What I have taken from that is I"m being paid to handle the details. They just want to know where we're at.
I have noticed is each client needs to be communicated with clearly, but how each may need their information may be a tiny bit different.
Maybe get a list of your clients exact concerns and a few examples. If his perception is that "managing" is causing delays in a deliverable, that can be addressed. It would be best not to try and answer him on them right away, just say you will take what he says and analyze what he's saying to see what might be possible.