Do you conduct a Specification Review?
What is the step that the client should undertake after an initial meeting? We think it should be a "Specification Review".
Generally a client wants to know if his idea will be $50K or $150K.
A "Specification Review" is performed to determine the overall scope, feasibility, and ballpark of the project. 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 should remove some functionality.
- Figure: Have a frank & open interview style meeting with a data projector to get everything out on the table
The Specification Review should be paid work and 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
- Interview: During the Spec Review, obtain an overall 'outsiders' understanding of the business and project through an interview process with senior
management, relevant business users and IT staff.
- 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, telling the client that "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 should 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 should 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. Squibbling over $5000 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.
-
"We believe the solution will take approximately 180 hours which is $36,900+GST"
-
Bad Example - Far too firm a price when you don't know any of the detail
-
"Our projection is the project will take a minimum of 6 man months to complete but this may change depending on what is finally
agreed in the Specification. The price will vary depending on resources used. We propose to firm up a price for the first 3 releases and conduct
a spec"
-
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.
Test Please
The Project Manager must run a test please by other SSW Senior Architects and the Account Manager before anything is formally presented
to the client.
Do you create an Initial Release Plan and Ballpark?
- Figure: Remember, a batter aims to hit the ball way out of the ballpark. Don't set an indefensible boundary too early
The Initial Release Plan is a summary of the work required to complete the clients project and provides a ballpark
estimate. The Initial Release Plan will contain the following elements:
- An architectural roadmap recommending technical solutions
- Time allocated for further specification work both at the beginning (Release 1) and further down the line. At SSW we only create
detailed specifications for 3 releases at a time
- A breakdown of the required software application into its core components, likely to include the approximate number of main features
(e.g. screens, reports or sitemap)
- An integration plan
- A deployment strategy
- A 'future functionality' wish list - requiring the client to set the priorities for the project through defining what is in and out of scope
- A detailed list of 'issues' associated with the existing system which impact future development and maintenance
- Hardware and licensed software recommendations
- A sample mock-up screen where the project is less than one month
Sample Initial Release Plan
- Release 1 (1.5 man months) - Specification (mock up screens, customer stories/business rules) (Releases 2 - 4)
- Release 2 (1.5 man months) - Database schema design
- Release 3 (1.5 man months) - Development Module 1 Customers
- Release 4 (1.5 man months) - Development Module 2 Products
- Release 5 (1.5 man months) - Specification (mock up screens, customer stories/business rules) (Releases 6 - 8)
- Release 6 (1.5 man months) - Development Module 3 Orders
- Release 7 (1.5 man months) - Development Module 4 Suppliers
- Release 8 (1.5 man months) - Development Modules 5 Employees
With the Initial Release Plan, the client can see whether SSW understands their business and the requirements
for their software development project. The ballpark estimate allows them to decide whether the project is feasible
for their budget and time-frame.
Do you conduct an architecture and code review every release?
An internal architecture and code review is the application of the Test Please principle
against the design phase. An architecture or code review conducted during every release, while adding a cost to the release for the time spent
conducting the review, will minimise errors, both small and strategic, which will save costs for both the supplier and the client down the line.
Schedule a 2 hour (2 architects x 2 hours) review during all releases. While it may not be so important to conduct a review in every
development release, they are compulsory for a specification release and one should be held for every week of specification time.
The following are items that are address in a architecture/code review:
Background information/overview of the project
- Current system
- Objectives of the system
- No. users (internal, external, edit, read only
- Current technologies
- Current environment (SOA, SOE)
Points for discussion
- Rich client
- Web client
- Smart client (any disconnected users?)
- Technology choices
- Persistance layer (SQL Server, Access, SQL Express, LINQ, netTiers)
- Business layer
- UI
- Communications
- Workflow
- Integration - external systems
- Requirements for 'package' software
- PerformancePoint
- Reporting Services
- Accounting packages
- SharePoint
- Data migrations
- Data reporting
- Data entry/user interaction
- Network
- Responsibilities/players
- Infrastructure
- Deployment
- Staged implementation
- In parallel
- Development/Test/Staging/Production
- Disaster recovery
- Change control/source control
- Build Server
- Performance
- Scalability
- Extensibility
- Design patterns
- Maintaintability
- Reliability (failover servers?)
- 'Sellability' i.e. is the solution appropriate for the client?
-
Do you effectively present the outcomes of the Specification Review?
- Figure: It's a lot easier to get a signature when you've got the right people in the room
The findings of the Spec Review (the Initial Release Plan) should be presented at a meeting with the key decision makers of the project for
review and acceptance, generally in the form of a PowerPoint presentation. It is important that all the required people are in a room together
to review the Initial Release Plan.
If you've run the Spec Review successfully the client should not be surprised by anything you present. This means discussions should focus
on issues such as what particular requirements could be added into the scope in the first phase, or what releases can be completed by what date,
rather than spending the meeting helping the client regain consciousness after they blacked out from seeing the price.
The Spec Review presentation should be scheduled by the Project Manager or Account Manager for the afternoon of the final day of the Spec
Review, or if the Spec Review is short (less than a week) in the week following. A proposal can sent following the conclusion of the Spec
Review but at SSW we generally email the PowerPoint presentation to the client as we are already operating in a contractual relationship.
Once again the presentation needs to pass a 'test please' from another SSW Senior Architect and Account Manager before the meeting takes place.
Do you obtain approval for the Initial Release Plan and Ballpark?
The client will already have entered a contractual relationship with SSW. It is not absolutely necessary to issue a new proposal for
the commencement of Release 1. SSW is happy to commence working on Release 1 once the client has agreed to the Initial Release Plan.
Agreement can be verbal with a confirming 'as per our conversation' email from the Project Manager.
-
Do you do schedule further specifications and create a detailed release plan?
- Figure: Schedule time to dig a little deeper. There's always another layer to uncover
More specs? How much is too much?
An over simplified way of differentiating Agile methods from Waterfall methods is to say Agile does the least amount of preparation
required to get something into production, while Waterfall does the most. Taking into account commercial realities SSW recommends an
agile approach. But the question remains, for your specific project, how much of the whole project do you need to know in detail
before you start coding?
The answer varies from project to project and those with the responsibility to provide the answer are the architects on the project -
subject to peer review. Having said that our standard is to schedule an entire Specification Release immediately following the Specification
Review, with further required, depending on how much you achieve in each Specification Release. The general rule is every forth release
is a Specification Release.
What is a release?
SSW develops software in Releases. A Release is a detailed task list of work items and their deliverable elements together with the time and
cost estimates associated with those tasks. A Release is 2 - 3 duration weeks and has between 2 - 6 resources allocated depending on the
project size and completion schedule.
The term "release" implies the unit of work is delivered at its completion, but delivery can be either public (i.e. to the client) or private
(i.e. just to the development/test environment). It is common for the first 2 - 3 releases (e.g. Specs & Database) to be private. Short
release cycles ensure clients have continuous visibility on progress.
The first Release for projects of greater than 1 month is a further period of specification and the creation of a
detailed Release Plan for, generally, Releases 2 - 4.
What's in a detailed release plan?
A release plan is a list of the releases in the priority order in which they will be developed (as agreed with the client). The 'details' are a
breakdown of all the tasks required to be performed in that release (including all the forms, functions, objects, stored procedures etc,
possibly a few mock up screens, and importantly, the business rules/customer stories related to those tasks.
To physically create release plans at SSW we use either eXtreme Emails! or TFS and MS Project. This makes constructing a
release plan as easy as clicking a button!
SSW offers four options for mockups.
Do you know how to estimate a Release?
Release contain two main classes of work: work items relating to the particular release (e.g.
Create Customers.aspx) and work
relating to all releases (e.g. management, administration, testing, software audit etc).
Project specific work items many only make up between 25% and 50% of the total project time. Project Managers
and developers should not think that the only work being charged on a project are coding tasks.
General Project Costs
Management costs can change depending on how much management the client requires. SSW will recommend a suitable level of management.
'Management', or to put it another way: 'accountability and transparency' has a cost.
At SSW we add general project costs as a % of the work items generally in line with the following:
- Unit tests: 20%
- Testing: 10-20%
- Fixes from testing: 10-20%
- Software Audit: 4 hours per Release - usually conducted by two experienced architects
- Fixes from the Software Audit: 5%
- Project Administration: 5% - this includes items like stand up meetings, timesheets, standard updates
- Project Management: at least 1 day per week per resource on the project (e.g. two developers full time requires a PM two days per week)
UNLESS the client provides a full time Project Manager and takes full responsibility for all resources
- Unknowns: 10%. While this is arbitrary it raises awareness for everybody that 'there are things we still don't know!'
Project Specific Costs
At SSW, estimates for a project will be done by a developer, checked by another developer, and finally triple checked by a project manager.
While every project is different in some way, there are common elements. SSW has built an estimates calculator to assist in creating estimates.
See the SSW Menu Estimates Calculator
If the client requires a fixed price quotation a 20% premium is added to the estimates for the releases specified in the
Specification Release only (i.e. a fixed price is not given on the entire project). Requests for variations to a fixed price
contract must wait until the contract is completed. If development is based on a fixed price contract work is completed
offsite only to facilitate project management and prevent unauthorised scope development.
Do you obtain approval on the detailed Release Plan
Each Release Plan is treated as a separate proposal and must be signed off after review by the client.
-
Does your project manager coach the team on a daily, weekly and fortnightly basis?
- Figure: Does your project manager coach the team on a daily, weekly and fortnightly basis?
It's been called 'herding cats'. Managing both the client and the project team during the release development phase is critical.
Keeping development of the release on track involves closely maintaining transparency on the important variables
of project management: time, scope, budget and quality.
Methods for managing the project team can be broken into daily, weekly and fortnightly activities.
Daily
Weekly
Fortnightly
Do you know how to complete a release?
Completing the Release draws a line in the sand in the project, allowing for a review of performance thus far and confirmation
to proceed to the next release. The process for completing a release is exactly the same as the fortnightly activities listed above
EXCEPT you should not conduct an archictural review.
-
Handover, support and warranty
Implementing a Support plan
Just like a car, applications need servicing and tuning every now and then to stay in top condition. They might need
alterations to deal with new business problems, or just tuning to increase efficiency based on changing user patterns.
Different clients need different levels of support. At SSW we offer a number of different support
offerings.
Important:When User Acceptance Testing(UAT) begins and there will be 30 days warranty period
to test the application by the client and report any
bugs back to us for
free correction, after this warranty period, even bug fixing becomes chargeable.
During the warranty period, all feedback from clients should be moved to next release
unless they fall into the
bug definition. After all reported critical bugs have been fixed, you
may generate a release plan for the next release and ask for approval to start a
new release.
Warranty on a Fixed Price Contract
The Project Manager should review the specification, check off and test all items.
This will determine whether (in his opinion) all items have been completed in totality.
The specification and project is handed over to a Tester (not a developer on the
project) and the Tester reviews the specification, checking off and testing all
items. He determines whether (in his opinion) all items have been completed in totality
Bugs and enhancements are made if required
When the Tester and the Project Manager are agreed that the project is completed:
- If a Client Review has been scheduled into the specification send an email using
(at SSW we use ClientDiaryCategory "12 Fixed Price Handover (Review)")
- If a Client Review has NOT been scheduled into the specification send an email (at
SSW we useClientDiaryCategory "12 Fixed Price Handover (No Review)")
Note: The warranty period pauses when the client reports a bug. The warranty period
resumes when a new version is sent. For example, the client may report a bug on
a Wednesday morning on "Day 18" of the warranty. The bug is fixed on Friday
and a new version is sent late in the afternoon. The warranty period resumes on
Monday morning, at "day 18". Therefore Wednesday through Friday were not
included in the warranty.
Note: There is no warranty on a time & materials contract
Leaving Incomplete/Untested Work
If, at the end of the day, work hasn't been fully tested, or is incomplete and you
haven't been booked in for the next day, speak to the Company Champion that issues
may arise and further work is likely to be required. After the conversation, email
the Company Champion and CC your manager to confirm that further work is required.