Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
Having done your homework, you should receive the formal brief. The most important part of any brief is to get it in writing. By this stage you've probably already received a fair bit of information about the project, but getting the brief in writing ensures that you and your team are able to respond to it in the most effective manner possible.
Quite rarely, however, will the initial brief be in a satisfactory form whether verbal or in note form. As a result, it's often up to you to turn the client's wishes into a coherent, written brief. Rather than make this a separate document in its own right, it is often best to incorporate this as part of your pitch, which we'll look at later.
Getting a client to articulate his or her requirements is one of the toughest things you'll ever have to do as a project manager. Worse still, clients rarely differentiate between incorrect assumptions you've made based on the absence of information, and assumptions you've made that are simply plain wrong. The way around this problem is to ensure that all the assumptions and guesses you're making in your pitch are based on the best and most exhaustive information available to you. As a result, you must be thorough in extracting the minutiae of the client's business requirements at this early stage.
| Note | Wherever possible, try to glean a phone conversation or, ideally, a meeting with the client before writing the brief and responding to it. |
If you are fortunate enough to get a phone conversation or meeting with the client from which to construct the formal brief, it's important, therefore, to ask the right questions. You need to focus on a number of key areas that are covered here. After you have gone over these, you will be in a position to write your brief.
Establish exactly what the broad requirements of the system or application you are building are at this stage. Focus on asking questions about the goals of the domain experts rather than the anticipated solution the client has in mind.
It doesn't matter if the solution you recommend is nothing like what the client is expecting, as long as you can precisely map your decisions to the goals of the domain experts. These mappings form the basis of your overall solution's rationale and are a key component of your pitch.
Ask leading questions. Try to listen rather than talk. The unprompted musings of the client can be immensely useful in optimizing your proposal to best suit his or her needs, even at a subconscious level. Try to effect a strong mix of commercial and logistical probing. For example, the following generic questions may be useful:
What other solutions have you looked at?
Why have you rejected them?
Who will the end users of this system be?
How are you currently handling this process without a system in place?
What benefits do you think the system might bring?
What kind of return on investment are you looking for?
How will you measure that return?
What are the three most important requirements you have of a supplier looking to provide this solution to you?
How many other suppliers have you looked at?
How satisfied have you been with the proposals you have received to date?
Do you have a time frame for choosing a supplier, and what is driving this time frame?
What people are likely to be involved in the decision-making process, and what are their roles?
What are the biggest concerns you have about this project moving forward?
Have other suppliers addressed those concerns to your satisfaction?
Again, don't be afraid to let the client do most of the talking. Try to avoid letting individual points drop as you scribble down notes; instead, ask probing questions to extract that "extra ten percent'' from the client.
Here's an example dialogue between supplier and client:
| SUPPLIER: | Do you have a time frame for choosing a supplier? |
| CLIENT: | Absolutely. We'll have made our decision by the 30th. |
| SUPPLIER: | The 30th of this month, really. You guys are keen to get this off the ground, then? |
| CLIENT: | Definitely. We've got a big marketing drive starting next month. |
| SUPPLIER: | Oh, right; is this system likely to be a big part of that marketing drive? |
| CLIENT: | Yes. If we have the build under way by then, it will definitely be a big selling point. |
Compare the same dialogue without the additional probing:
| SUPPLIER: | Do you have a time frame for choosing a supplier? |
| CLIENT: | Absolutely. We'll have made our decision by the 30th. |
| SUPPLIER: | Great, thanks. |
Notice the extra information gleaned from the probing:
The client has a marketing drive taking place next month.
The client would like to be able to show the unfinished system to prospective clients as part of his or her sales pitch.
This information is no secret, and the client isn't holding back deliberately it just hasn't occurred to him to mention it. But make no mistake about it: This extra information should be very useful to you, indeed. The moral of the story is don't be afraid to take an interest in what your client is saying and ask the extra questions that might get you that extra nugget of information. It might just give you an edge on your competition.
We have established the broader business requirements of the system and worked out exactly what problem or need the client is trying to solve or fulfill. However, it's worth probing the client some more about the scope of requirements. Let's be clear about what we mean by the term scope here. By establishing scope, we're looking at how far we are going to go to solve that problem or fulfill that need.
People often speak of scope-creep, which refers to the magnitude of what's required growing in the middle of the project without regard to commercial impact. By establishing the scope now, you can prevent this from happening as much as possible. The specifications you produce allow you to enforce this chosen scope by mapping it to the specific components of functionality that will be included in the build process.
Scope is almost always artificially throttled by time and money. However, it can be a useful exercise to help manage expectations even at this early stage by drawing phase boundaries. Nine times out of ten, suggesting a two-phase approach to the client can help you immensely because the client will instantly illustrate for you the kind of functionality that might drop into a second phase of development and the kind of functionality that is required now. Commit to just the latter of these, and you have your initial scope well and truly defined.
If the client is reluctant to look at phases, a more direct approach is needed. Explain to the client that the only limitations in meeting his or her requirements are those of time and money, and that understanding what the absolutely essential components of the project are now can make life easier for the client, in so much as he or she will be able interpret proposals on delivery time and cost on a more equal footing. If no other suppliers are pitching for the work, explain to the client that establishing scope now will save huge amounts of time later and allow the project to progress more quickly with fewer revisions to specifications.
Establishing timelines is about much more than just figuring out when the client needs the system to be delivered. It's vitally important to set milestones and agree to them with the client even at this early stage. You should try to gauge milestones for the date by which:
the proposal is required
a decision will be made on a chosen supplier (if appropriate)
any written specifications are required from the supplier
any written specifications will be signed off by the client or, if amendments will be required, those amendments will be tabled
the specification process, including all amendments, must be finished
any designs produced by the supplier must be put forward for initial approval
any designs, including all amendments, must be finished
the build must commence
the build must be completed to beta standard
the build must be completed to finished standard
testing must take place
the handover of the finished product must take place
Of course, asking for all these dates from the client may well overwhelm or even irritate him or her. To avoid this side effect, pick what you consider to be the key milestones and fill in the blanks yourself. You can even have a positive effect on the client's view of your processes at this early stage by announcing where the dates will fit together. Consider the following snippet of dialogue:
| SUPPLIER: | When do you need the completed system to be handed over? |
| CLIENT: | We need to be up and running with the staff by the 1st of June. |
| SUPPLIER: | In that case, we should aim to have the system handed over to you by the 22nd of May, to allow a few days for any last minute tweaks and changes that might need to be taken care of. |
Don't forget to note all milestones carefully throughout the briefing process and, when necessary, guide the client away from any unrealistic expectations, as shown in the following example:
| SUPPLIER: | When do you need the completed system to be handed over? |
| CLIENT: | We need to be up and running with the staff by the 1st of May. |
| SUPPLIER: | I think that given the kind of scope we've agreed on, that is going to be a difficult date to meet. I would suggest a delivery date of 22nd of May is probably closer to the mark, which should have you up and running shortly afterward. I think we have two options: We can either reduce the scope of the system at this stage, or we have to look at a slightly later delivery date. |
| CLIENT: | Well, in all honesty, we could live with the 22nd. Rather get it right first time. |
Notice how we use passive language in explaining to the client that his or her date is unrealistic. We do not "tell" the client, because he or she may well think we are attempting a "we know best" tactic, which might offend. Rather, we "suggest," and in many cases, as in the preceding example, you'll often find that there is a little more room for maneuver than originally stated.
Always be sure to point out unrealistic dates; never let them slip. The client will expect anything unattainable to be pointed out now. If it is not mentioned until your written proposal comes through, you may risk alienating the client, especially if the client has already told others involved in the project of the anticipated dates. Essentially, anything not contradicted will be taken as tacit agreement, so beware.
Budget can be a thorny issue. Even if you are delivering a solution internally, you still have your direct costs to think about. Many larger companies bill each other's cost centers for internal activity, so budgeting and negotiations can be just as intense for internal work as they for an external commission.
Don't ask the budget question too early. It is immensely off-putting. The client expects to be asked it, but may quickly judge what he or she deems to be your own priorities as a supplier based on the order in which you ask questions. The right time is probably close to when the subject of scope is raised, because you have already established that scope is more than likely going to be limited by time and money.
A good way to phrase the cost question would be: "When I've looked at implementing similar solutions to this for companies like Acme in the past, they have typically been expecting to invest between $25,000 and $45,000. Does that sound like the kind of ballpark you had in mind for this project?''
Note that, first of all, you haven't asked what the budget is. Rather, you have suggested that:
You have worked on similar projects in the past positive
You have worked with companies like Acme in the past positive
These companies have invested anywhere between $25,000 and $45,000 neutral
The emphasis on the positives in your interrogation means that the negative thoughts associated with determining budget will not kick in quite as automatically as they would if you were to ask the question directly.
Note that, second, you have offered a ballpark range. This range is, in fact, quite broad. Always do this; to be too specific at this stage suggests arrogance with respect to an understanding of the client's requirements, which you don't have yet. By suggesting a broad price range, you suggest subconsciously to the client that you still have yet to zero in on exactly what is required. Make sure that the minimum you suggest is the absolute minimum you're prepared to do the work for, and the maximum is about 40 to 50 percent more than that figure. That way, if the client agrees, you know for sure that you will have a profitable job on your hands. By how much remains to be seen, true; but you've negated the chances of a loss-maker.
Note, finally that we have used the phrase "they have typically been expecting to spend.'' We have used this in preference to "we have typically quoted them'' for a good reason; namely, that you are suggesting that these companies actually anticipated spending this amount before they spoke to you, not that this is the amount you quoted them.
This does not, of course, answer the eternal question of "what is your budget?'' What it does, generally speaking, is implant a firm idea in the head of the client as to what the project is actually worth in market terms.
If, upon becoming aware of this knowledge, the client realizes that there simply isn't the budget to proceed, he or she will usually tell you. This obviously isn't a good thing in itself, but it does allow you to judge very quickly whether your time put in receiving the brief is time well spent. Consider the following two approaches. In both dialogues, the supplier needs to charge around $15,000 just to break even on the application; the client's budget is only $5,000. Here is our first scenario:
| SUPPLIER: | Did you have a budget in mind? |
| CLIENT: | I'd rather not give you a budget. When we've done that with suppliers in the past, they've simply come back and quoted what I told them my budget was. I'd rather you just went away, came up with a quote, and I'll tell you if it's doable or not. |
| SUPPLIER: | OK, no problem. |
Contrast this with:
| SUPPLIER: | John, I wanted to broach with you the issue of budget. When I've looked at implementing similar solutions like this in the past, they have typically been expecting to invest between $15,000 and $22,000. Does that sound like the kind of ballpark you had in mind for this project?'' |
| CLIENT: | Oh . . . no, it really isn't. I'm afraid the maximum we can afford to part with is $5,000; maybe $7,000 at a push. |
| SUPPLIER: | Okay, John. I'm afraid I don't think we're going to be able to do business on this occasion, but thank you very much for your time. |
In neither situation does the supplier get the business. But, in the second situation, the supplier knows straight away that there's no sale in sight, whereas in the first situation, days would be lost creating a comprehensive pitch, only to be turned down later.
Don't get embarrassed about asking about money. Be up front, and pick your language and your timing carefully.
It can be worth talking about commercial terms, even at this early stage. If you've established that the client is happy to pay approximately $50,000 to have his or her project developed to completion, this is certainly a good start but certain technicalities that often don't get mentioned can pour cold water on this head start very quickly.
As with budgetary concerns, it's far better to get the issue of commercial terms out of the way early, so that if they prove to be stumbling blocks, you can be aware of them now and back out if necessary. The following questions are probably more relevant to smaller businesses rather than enormous technology agencies, but are still worth asking if you have any payment-related concerns:
"We normally like to ask our clients for an up-front percentage contribution so that we can cover any incidental costs during the build process. Would this be a problem?''
"Because we're a small company, we have to be quite strict with our payment terms. All our invoices are strictly 30 days. Do you think this would be all right with your accounts guys?''
Again, phrasing is very important here. For example, the use of the friendly interrogative statement, "Would this be a problem?'' is highly recommended. You are far more likely to solicit a sympathetic "Oh, no, I wouldn't think so'' response, rather than something more aggressive or perfunctory.
Another stock phrase is "Do you think this would be the kind of thing that could stop us doing business together?'' It sounds incredibly emotive, but it suggests "no'' as an appropriate answer in its tone, and so is much more likely to solicit that kind of answer. Positive responses are useful not just because they're what you want to hear, but also because they're what the client wants to say.
| Hint: | Research suggests that a meeting in which parties have used positive words and body gestures leaves a far better impression than one littered with "no's'' and shakes of the head. |
By leaving your client with a positive impression of the meeting, you're leaving him or her with a positive impression of you as an individual.
As far as is reasonably possible, you should endeavor to press the client for his or her future plans for the system. You may well have determined what is "in-scope,'' but it is equally important to know what is both "out-of-scope'' and equally likely to become a requirement in future.
As a software architect, you may be more than familiar with the concept of "coding yourself into a corner.'' The best project managers are aware of these concepts, too, which is one of the reasons that many of the best project managers tend to have backgrounds in architecture.
Determine as early as possible what is likely to become a requirement at a later date, even if it is conceivable or likely that another supplier will be taking the work on. Showing interest in what is clearly not going to be paid for or carried out at this stage demonstrates a commitment to avoiding "hit and run'' programming, and shows that you are the kind of supplier with whom the client can forge a long-term relationship.
There is no excuse these days for even the simplest of Web applications not to look good. Design needs to be an integral part of your process, not just an afterthought, and this should be emphasized to the client whenever possible.
Determine at this stage whether any requirements or specific requests exist on the part of the client with respect to the look and feel of what is being produced. Is there an expectation, for example, that a particular corporate branding is followed? Does the system need to closely resemble an existing system? How likely is it that the branding will change, and how often?
There's a good chance that the individual you are dealing with from the client company is not a technical person. For most projects, this is understandable because the goals of the required system, for which you are receiving the brief, are unlikely to be technical in nature. Even with this in mind, it is an immensely good idea at this stage to ask probing questions about technology.
Essentially, you need to gauge how much of a free reign you have on making these decisions. In your written proposal, you need at the very least to outline the platform and infrastructure choices you have made and be able to justify them if necessary. Aim to ask the kinds of questions that will determine whether the client is happy for you to code with PHP, what deployment issues there may be, and also what security issues might arise.
If any restrictions you discover look to be onerous, this may be another red flag a sign that you need to cut your losses and pull out. As a PHP professional, if the client insists on ASP and SQL Server, you would be wise to think about declining the work or, alternatively, trying to convince the client that PHP is the way to go.
Either way, it is a conversation you must have early, to prevent any fruitless pitching.
If there's one thing you should always try to raise with the client, it's the issue of after-production support. It may not have even crossed a client's mind, but it's extremely useful to establish what the client's expectations are and how they tally with your own.
Determining who will create user-orientated documentation (if required), who is to provide support after the system is deployed, and what kind of service the client expects during handover are all important issues to address. If the client appears at a loss, attempt to suggest suitable answers to your own questions, and gain client's tacit approval for inclusion in your pitch.
Now that you have a formal brief, it's time to proceed with winning the business. If you're in the fortunate position of developing a project for another department in your own organization, you can probably skip the next section.
If, however, you need to actually convince the client of your worthiness as a supplier and provide a fully costed proposal in the process, read on.