|
|
| Subject | Author | Richinger
Global user
(5/28/00 5:51:58 pm)
Reply | Edit | Del All | Estimating project req'ts prior to hourly contract
I posted here 7-8 weeks ago, about an opportunity to do a time-and-materials contract direct with a former client. Even as slow as this company has historically been, I never would have guessed that they would have taken this long to iron out the details. It now appears that we are about to meet for our third time to come up with an estimation of total hours and thus a purchase order.
This project would be a windfall for me, and I don't want to screw it up in the early going. Aside from the direct consulting and bigger dollars, it represents some new technology for me that seems like it's impossible to get otherwise. I live in a pretty technologically "secluded" part of the country, and finding this kind of opportunity (and sometimes just work at all) is next to impossible.
My quandary here is how to handle the client's need to come up with an estimate of the total hours for the project. In my consulting projects of the past, the clients have been somewhat more software savvy than this one, and willing to go pretty much on a quarterly purchase order. This client seems to want to come up with an early estimate of the total effort and cut one "Hail Mary" PO for the whole thing. While the project requirements are pretty fuzzy at this point, I think I know enough to SWAG a number for the whole thing. My answer will probably be something like, "6-12 months, depending..." but I know that the client will immediately ask, "depending on WHAT?" and I really don't want to provide any further detail. For one thing, I don't really know enough to get into it, and probably more importantly, I believe that the additional detail is what they are paying for in the first place.
I do believe that the client would prefer a fixed price arrangement, even though I've told him I will only go hourly on this. Can anyone give me some pointers on how to handle this situation, so as to provide the answers he's looking for, but at the same time avoid painting myself into a scheduling corner that might ultimately prove embarrassing to extract myself from.
Thanks for any perspectives.Edited by Richinger at: 5/28/00 5:51:58 pm
| James V Reagan
Unregistered User
(5/28/00 8:10:26 pm)
Reply | Edit | Del | Start with a PO for an analysis phase
I typically start an engagement with a client for a small amount of time (1-3 weeks, depending on scope of project) doing what you describe: coming up with a proposal for the client: deliverables, timelines, projected budget, etc. It can be as comprehensive as you want it to be, but in order to come up with something of benefit it will take more than a couple hours, and you're right: this is information that the client should be paying for.
Try to sell them on a small number hours up front to come up with a plan. As far as pushing back on fixed-bid, that's fine. But educate your client on their risks of going fixed-bid, and what they would need to do to get anyone willing to bid on the project.
| RMP
Local user
(5/29/00 5:33:52 pm)
Reply | Edit | Del | Re: Start with a PO for an analysis phase
Right, and if they seem reluctant, ask them if they'd expect a builder to build a building without a blueprint, or to even give an estimate for it. Tell them that the spec. and design phase(s) are part of the actual work involved in producing their desired result, in fact, the most important part of the work, because if those are screwed up then the whole project is doomed. Well, maybe find a nicer way to put it, but if you have to scare them a bit to drag them into reality, then do it. Good luck.
Robert M. Pritchett,
President - RMP
Consulting Partners LLC
People -
Openings -
Benefits -
Fees -
Acid Test -
Umbrellas -
Per Diems -
Y2K -
IRS
| PFreyer IC
Global user
(5/31/00 5:29:48 pm)
Reply | Edit | Del | Re: Estimating project req'ts prior to hourly contract
Give them some d**n ballpark figures!
You don't have a signed contract, so therefore you're still in the qualifying stage.
The client is still trying to qualify that you and this project are within the price range they want to spend, and you'd better know that too. Software projects invariable cost more than the inexperienced client anticipates, and you'd hate to spend any more of your time on this prospect only to find that you weren't on the same playing field, wouldn't you? What happens if you ballpark $250,000 and the client was expecting $80,000?
What happens if they expect the project to be completed in 4 months and you say 6-12?
As you've identified, the client is not particularly software savvy, so they are looking to you as the expert. They're about to drop some substantial dollars into your pocket, and they'll continue to need reassurance that you are the right person for the job. This is the consultative selling cycle. Do it in a likable, informative, open and non-condescending manner, using this third meeting (and subsequent meetings) as a prime opportunity to educate and inform them, and in the process, you will develop their trust and confidence in you, and strengthen your business relationship with them. It's the perfect opportunity to raise your credibility with your client even higher, and it's being handed to you on a plate, without you even asking for it!
So, without giving away your 'trade secrets', share some of your expertise!
Project management and software implementation or development plans are not some kind of industry or trade secrets that must not be given away to the client. They're just some of the tools of the trade, and they're more of a science than an art. Your variables (the 'depending on WHAT' that you identified) are not much of a secret either, basically your biggest variables are in the quality and quantity of your project resources, the stability of the chosen technology, the ability to get necessary decisions made in a timely fashion, and the discipline of the client in sticking to the scope of the project. Telling the client this does not give anything significant away, and doesn't require much more elaboration.
You can site some experiential information, with a very broad range of figures to further instill confidence that you know about what you talk, using the high and the low, such as "when I implemented 'small manufacturing company' with a,b and c, it took 123 man months and abc resources and cost $abc, compared with implementing 'major corporation' which took 789 man months and xyz resources and cost $xyz. Of course, you have some individualized requirements and a different version/release of software/technology, but I anticipate that you'll probably fall somewhere into the middle of this range."
You can also ballpark with some industry standards, or base it on how much they're spending on software, such as "typically, it will take you somewhere between $abc and $ghj dollars to implement software that costs $abc".
You can also give them some alternative project scenarios, based on variables in project staffing using contractors versus internal resources, internal percentages of time dedicated,and variations thereof etc. Then ask the client for some parameters or assumptions about the variables that you should use in developing the detailed project plan. For example, will you have a user team working with you, who will be the client's decision maker and how fast should you expect decision turnaround, will you have any dedicated project resources or expert team members, do you have any authority or responsibility for the project budget, can you bring on contract resources yourself or does it have to go through an approval process, etc etc?
Yes, you're going to have to wing it just a little on the unknowables of the technology, but this is less significant that you think. I'm sure you can flush out some of the info that you'll need to help you estimate (eg XYZ software has the reputation of being buggy and a pain to implement but cheap, whereas WXY software is solid, easy to implement but the technology is old, etc), you can probably even get some of it from the software vendor or technology supplier. Compare other aspects of the project with other projects you have known - size or dollar or resourcewise there are bound to be similarities.
But for starters, you can give them the overall game plan and general methodology. Show them a project plan in a draft form, including a scoping stage, which outlines in detail the process and preparation work that must be done in order to firm up the rest of the plan estimates.
And I will tell you this in all honesty. If I walked into my third meeting with you and you couldn't give me a ballpark more specific than 6-12 months and refused to outline the variable factors to me, your expertise would be in doubt and you'd loose credibility in my eyes.
However, if you handheld me through one of my first software projects, educating and helping me to become a much more savvy software consumer, and didn't laugh at my newbie questions or mistakes, I would look very favorably on you the next time a project came around!
| NetArchitect
Unregistered User
(6/3/00 3:54:32 pm)
Reply | Edit | Del | 5-step approach, deliverables at each...
A company I worked for long ago had a 5-step project consulting methodology that went something like this:
Each step had a specific focus and goal - to produce a deliverable document which feeds the next step in the process. No steps can be skipped - no going right to "solution design" - which is where most companies want you to start on day 1.
To be honest, it all sounded like a bunch of Big-6 hot air, but when I go back and look at some of the documents I produced under that methodology/framework they are far better than what I usually come up with when I'm winging it.
The key to the process is the deliverable - the next step can not begin without having the deliverable document from the previous phase. This also gives the client the option to "cancel" you at any time, and turn over all your documents to someone else -- clients like this if you make them feel like it protects their investments (which it does).
From my rough memory, the steps of the project were:
Documentation of Current Environment
Documentation of Desired Environment
Analysis of Requirements (i.e.: what it will take to get from current environment to desired environment)
Development of Solution (i.e.: must meet requirements defined in previous step)
Planning the Implementation (i.e.: no implementation can/should be planned until a working solution is in place)
Most clients want you go right to the solution design - but until you truly understand their organization, you can't design an effective solution. So you go through the documentation of the current environment and review it with the client. Have a formal meeting where everyone agrees to the document and there is a sign-off. Once that is complete, you move to step 2 and repeat. Once you have 1 and 2 done, you can begin defining the requirements (i.e.: Messaging system must support X.400 and SMTP based messaging). Once the requirements are defined - again, hold a meeting with everyone and have the client review the deliverable documents. Get a sign-off that it is acceptable. Can you see how this goes?
The great part for the client is that if at any point in time they're unhappy with you they can cancel you and feed your documents to another consultant. Hey, none of us ever feels that it should ever happen to us, but things like that make clients happy. The client will be happy to know that they can simply take the deliverable documents from the first 3 steps - all the way up to the requirements definition - and hand it to someone else to actually develop the product.
The great part for you is the sign-offs, the confirmations that you are on-track each step of the way. Scope creep, and relevant efforts outside of scope are huge project killers - and they can be tracked (IMO) to an adequate lack of communication from the start. So get them to agree at each milestone that you are on track. Have them agree to the document and sign it. Make sure all invoices (within your "net xx days" terms) are paid up. And THEN move on to the next phase.
Plus, you'll have some killer looking project documents to use when working with your next client.
Best of luck,
Douglas Toombs
Owner, NetArchitect Consulting
Co-Author, Mastering Windows 2000 Server
| Dinosaur
Local user
(6/3/00 5:04:11 pm)
Reply | Edit | Del | Any plan is better than no plan
NetArchitect's 5-step plan, or a 10-part SLC framework, or whatever.
The hard part is keeping client focused on the current phase, not jumping ahead. Most users want to go directly from a 1-hour exploratory meeting to a full scale systems test, and into production by the third meeting.
The part about getting signoff at each deliverable event is crucial.Over what hill? I don't remember any hill!
| Richinger
Global user
(6/3/00 6:27:54 pm)
Reply | Edit | Del | eMOREDATA
Thanks for the helpful suggestions. I took James' and RMP's suggestion to our meeting last week, and suggested a contract to do the design work up front. Client was not averse to this, but now wants me to submit a proposal for what I want to do for them. Says that Purchasing has to have "deliverables and milestones" to even take a second look at the effort (and cut a PO). Fair enough. As PFreyer pointed out, they are looking to me to provide expertise for how to proceed, and I'm glad to do it. I wish I weren't so under the gun financially; otherwise, this would be a breeze.
>>Give them some d**n ballpark figures!<<
For this project, that's a little like trying to toss a javelin thru a rolling tire (or "catch a falling knife," etc.). The client keeps expanding the scope of the project, with each of our three meetings. Even giving a ballpark figure is meaningless until they firm up what it is they want me to do. Since I've worked with these people before, this is by no means surprising, but makes it impossible to scope the project. "To do WHAT?" remains the operative question.
The client has indicated there will be NO funding [for my efforts] until there is a firm list of deliverables and milestones, both for the design effort, as well as the implementation. I expect to use this first PO (if it's EVER authorized) to come up with something that both they and I will be comfortable with. They mentioned this week that this will become a quite visible (and necessary) project for the company, and as such they want it "done right." So do I... I really don't want to come up short in my estiimates of what it will take to do the project, and this specifically means that the requirements have to be firmly specified before I can move forward. It is the fact that they are looking to ME to render the "requirements spec" (formally or otherwise) that has me concerned.
>>The client is still trying to qualify that you and this project are within the price range they want to spend<<
Without my being flipant, my impression is that the client wants me to do the project, and doesn't yet know what "price range they want to spend" to accomplish the end result. Neither do I, and the reason of course (as mentioned above) is that the requirements are not firm yet.
I've worked on proposal efforts in the past, some of them MANY years past , that have resulted in the client using my work efforts (for zero compensation), to define (and then award) the project to a lower priced bidder. Although I don't think that will happen here, it explains a good bit of my hesitation about being so overly generous with my free time to the effort that I give away the opportunity to do the rest of the work. Maybe I should be more generous, maybe not. The client has acknowledged that this level of effort on my part deserves to be compensated.
Since it's been years since I've done a "proposal," even for scoping the project, I am coming up short handed for more than just a crude outline of what I should provide, at least for a professional presentation. Can anyone make some suggestions?
Thanks for the thoughtful responses.
| PFreyer IC
Global user
(6/4/00 4:21:13 am)
Reply | Edit | Del | Re: eMOREDATA
As a business analyst and ex-developer, take it from me that one of biggest difficulties that developers have when preparing requirement specifications and project definitions is to avoid specifying the design. It's so tempting to explain how you're going to be addressing issues and resolving the users problems and meeting their requirements, but that's how you get your work 'stolen' and awarded to a lower bidder.
Keep this in mind as you perform the following activities:
Specifying the Requirements
As there is no RFP document, here's what I would do.
1) Request an information package from the business area in the form of their policies and procedures, instruction manuals, checklists, and sample screen prints, forms, reports etc. This generally doesn't take more than 2-3 days for the users to produce.
2) After studying the information, I would sit down with the key users, either in an group session, or in individual interviews, to discuss the business activities and work flows, and to obtain the likes and dislikes with the current systems/methods. Once you've performed this detailed needs analysis, you will be able to flesh out the detailed business requirements. Then you need to understand the business direction and tie it in with why they're doing the project- are business processes going to change as a result of the project, what will be the impact of the new software/ technology etc.
3) Summarize in a Requirement Specifications Document
Is your contact the project sponsor? Have you and your contact finalized a high level project statement yet? Does your contact have the business area knowledge, or is there a separate individual responsible for that, ie. a business owner or champion? For example, if the project sponsor is the IT Manager, and the project is of a billings nature, then the business champion might be the chief accountant.
Preparing a Project Definition Document
It will containing the following:
1) The High Level Project Statement
2) Background (explanation of how the project has come to be)
3) Overview (what it is going to do and a high level summary of the deliverables)
4) Objectives (statements starting 'to replace', 'to enhance', 'to streamline' etc)
5) Scope (summarize the functionality being addressed and the data being modelled, identify any legacy systems, the design stakeholders, and the scope exclusions - if in discussions the scope continues to grow, you might identify a phase 1 and a phase 2 of the project, with the 'must have from day 1' and 'nice to have later' requirements - then phasing becomes a tool to help control scope creep)
6) Approach (detailed tasks eg. development activites, reviews, workshops, evaluations, related to the deliverables)
7) Communications (ie the strategy - status reports, meetings, calls etc)
 Team (it names names, roles and responsibilities of client and contractor)
9) Deliverables and Milestones (a high level schedule, like a to do list)
10) Schedule (a plan listing the tasks, resources, start & finish dates etc)
11) Budget (tied to project or deliverables, and your payment schedule preferably)
12) Critical Success Factors (some of your WHAT factors and user perceptions such as 'if it doesn't do x or improve y then it's useless)
13) Risks, Assumptions and Constraints
14) Sign Off Sheet for Client and Contractor
All of the above is functional definition and none of it actually documents the design or the technical specifications of the software/system (that is all still in your head and in your rough notes). If you've done this right, then you'll not be giving away information that would make it particularly easy for anyone else to walk in cold, underbid you and develop the product in your place.
Prepare a bullet list version of this document containing just the highlights, to present to the client. If you're going to be compensated, get the client to pay for your time and the production of the Requirement Specification Document only. This will further serve to protect you. Once you get the deal, you should be able to charge for the preparation of the project plans, and use the project definition document as part of the contract since it defines all the scope, expectations, deliverables, signoffs, etc.
Hope this helps.
| Dinosaur
Local user
(6/4/00 6:00:49 am)
Reply | Edit | Del | This is a great thread.
It could be a chapter in Janet's next book. I just saved the whole schmeer.Over what hill? I don't remember any hill!
| David Randolph
Global user
(6/5/00 9:13:40 am)
Reply | Edit | Del | Re: Scope creep
>"The client keeps expanding the scope of the project, with each of our three meetings. Even giving a ballpark figure is meaningless until they firm up what it is they want me to do. Since I've worked with these people before, this is by no means surprising, but makes it impossible to scope the project."
This means that you are being asked to do two things:
a. project management
b. product development
If you are not comfortable with the first part, then this contract will be a tough one.
I would suggest taking one project out of the list of things that they have suggested and write up an action plan just for that one thing. Specify what that project is not doing and run it past them. You will need to contantly update the decision makers what is actually going on when the project scope keeps creeping or stand firm in not letting it creep.
One question needs to be "who is the actual decision maker?" For example, I had a project that was started and had a lot of project creep. I thought I was communicating with the decision maker and getting approval for the project to keep on going. It turned out that the owner's wife over in accounting was the actual decision maker and the project got abruptly halted when the costs went past what she thought it should take. It is real common that the actual decision maker is not the person that you are talking to in the early parts of the contract.
David Randolph
| NetArchitect
Unregistered User
(6/5/00 1:28:59 pm)
Reply | Edit | Del | Keeping clients on track....
>> The hard part is keeping client focused on the current phase, not jumping ahead. Most users want to go directly from a 1-hour exploratory meeting to a full scale systems test, and into production by the third meeting. <<
Agreed. This is the most DIFFICULT part of the process, believe it or not.
I dealt with this on the 2nd engagement where we used the methodology. I can remember the director of the government agency we were bidding on talking with me on the phone ...
"Why do we need to have these first two phases for $xx,xxx? It's real simple - our current state is Windows 3.1 and DOS on a Novell 3.x network, and our desired state is Windows 95 on a Novell 4.x network. We just need a solution."
We agreed to a 1-day (free) fact-finding meeting with them. Fortunately, our methodology had been engineered enough to have very detail-oriented questions to ask about all of their technical issues (i.e.: How are IP addresses allocated, How are share optical devices accessed, etc.) After walking through the boring minutae for about an hour, the director realized that when it got right down to it there was a lot of complexity in their environment and agreed to do the migration in the approach we designed.
Ironically enough, I was able to do phases 1-3 for them, and part of 4. They liked my documentation, and when another consultant came in to do the last parts for them they were toally disappointed with what they were provided with and wanted me back. Unfortunately for them, I was on another consulting engagement at the time. But a methodology - any sort of plan - always works out better than wigning it.
Best of luck,
Douglas Toombs
Owner, NetArchitect Consulting
Co-Author, Mastering Windows 2000 Server
| RMP
Local user
(6/5/00 1:40:48 pm)
Reply | Edit | Del | Re: eMOREDATA
The client has indicated there will be NO funding [for my efforts] until there is a firm list of deliverables and milestones, both for the design effort, as well as the implementation.
OK, give them the following list:
1. Do requirements/spec phase.
2. Use the output of 1. to create the list for the design phase.
3. Use the output of the design phase to create the list for the implementation phase.
If they want a fixed price now, give them this version:
1. Preliminary highest-level info-gathering requirements/spec. phase - x days, $y
2. Output of 1. includes fixed price and deadline for the rest of the requirements/spec. phase, each feeding the next, etc.
If they can't handle that, tell them you don't build a building without a blueprint, and you can create the blueprint but that costs time and money too, and the time and cost for the building can't be determined except by doing the blueprint.
If they still want a fixed price up front, give them an outrageous number e.g. $1M for what should be a $100K project and tell them that what they get for the $1M and how long it'll take need to be determined by the requirements phase etc. and it's not guaranteed to be what they think they want now because they don't know what they want yet.
Robert M. Pritchett,
President - RMP
Consulting Partners LLC
People -
Openings -
Benefits -
Fees -
Acid Test -
Umbrellas -
Per Diems -
Y2K -
IRS
|
|
