DEVELOPMENT SERVER
Rules to Better Work Items ( AKA Project Management )

A client will often ask for a proposal or ballpark for the project. It is very difficult to give them price for a large project without first conducting a specification review. 

A Specification Review is paid work conducted after the initial meeting to determine the overall scope, feasibility, and ballpark costs of the project (ie $50k or $500k). We encourage you to also create a detailed "Release Plan" for the first 2 releases. eg. Mr Northwind learns that the idea he presented at the initial meeting will cost approximately $80K and he has to determine if that is feasible to his business or if he will trim the functionality to better manage the cost.

Figure: A ballpark or proposal should start small and not be a big commitment
From this initial meeting the ballpark is 6 months and $200K+GST

Figure: Bad example - big scary figure

From this initial meeting we will first need to conduct a specification review. This first step is $10K
- Requirements Workshop (2 x ½ days)
- Specification Review (example image)

We will scope out the next two releases.
Figure: Good example - work in small chunks of work with details about what you will do

Open conversations

Figure: Have a frank & open interview style meeting with a data projector to get everything out on the table

The Specification Review is conducted by two experienced developers at the client premises in close consultation with the client. The time allocated for a Spec Review is generally 1 - 5 days depending on initial expectations of the project. The rule of thumb is 1 - 2 days Spec Review per estimated month of project time. The purpose is to understand the whole project but, if the project is greater than six months, focus primarily on the first six months. The Spec Review is a process that will demonstrate to the client whether you have the commercial sense to understand their **business** and have the technical and management capacity to complete the project.

Talk Business Process

• User Story Workshops: Conduct workshops with different groups of users (e.g. management, back office, customer service) to build the "user stories" which the business wants. This ensures you get all users get their say. Some "nice-to-haves" might actually be quite easy to implement. User stories can then be prioritised and fleshed out.
• Review Documentation: Reviewing any documentation the client may already have. Remember clients are mostly looking to software consultants to assist them in solving business problems.
• Technology: Warning: Detailed discussions about technology with the client, unless they have a specific business purpose, are unlikely to be useful. For example most clients won't be interested in a discussion about whether to use MVC or ASP.NET traditional at this stage.

Do something valuable

Most experts at software consulting will be able to provide a small improvement to the current system 'on the fly' during the Spec Review. This may be something as simple as adding an index to a table and thereby increasing the performance of a webpage.

Use 'Corridor Conversations'

Figure: Use corridor conversations to prevent nasty surprises

While the information collected and the conclusions of the Spec Review are presented formally at the end of the Review it is important that the Project Manager convey key points to the client as they emerge through the course of the Review. The formal presentation is NOT the time to be presenting new information to the client. Formal meetings can have an Us vs Them feel. Addressing key potential sticking points of budget and technology informally during the course of the Spec Review relieves the potential for unwelcome surprises during the Spec Review presentation. Canvassing the issues beforehand in casual 'corridor conversations' clears the decks for an agreement, rather than increasing the risk of heated discussions if you surprise a client at a formal meeting. For example, ask the client "building the cube will add around two months development time, shall we leave this out of the current scope, or do you want it in?" Remember, no politician challenging for the leadership ever calls a vote before he or she knows the numbers; you too will avoid presenting a solution at a meeting if you aren't convinced the client is already agreeable. Through the course of the Spec Review the client will by aware of at least the following:

Budget ballpark indications expressed in terms of man months

Each man month for senior software consultants is generally tens of thousands of dollars. Squabbling over $500 here or there in the ballpark phase is a level of detail neither side can be confident of. Clients needs to be realistic about what they get for their money.

"Now that we've spent a few days speccing this out, we believe the solution will take approximately 6 months which is $204,000+GST"

Bad Example - Far too firm a price when you don't know any of the detail

"Now that we've spent a few days speccing this out, our projection is the project will take a minimum of 6 man months (around $200,000+GST) to complete but this may change depending on what is finally agreed in the Specification. The price will vary depending on resources used and the time that elapses over testing.

We propose to do a $10,000 spec review and firm up a price for the first 2 releases."

Good Example - leaves some wriggle room at these initial phases

Technology options

At this stage you want to consider the most relevant technologies. For example SSW will likely pursue recent Microsoft technologies. Some clients might want to do their own research or need some time to think about their options before agreeing to newer technologies.

Proposal

You should follow Rules to Better Proposals when documenting a Specification Review.

Test Please

The Project Manager must run a test please by other senior staff before anything is formally presented to the client.