Rules to Better Project Management (XPDM)

Software must help a business become more efficient and build better relationships with their clients. Business need software to be produced cost-effectively and quickly. Simple steps upfront stop software being slow to build and difficult to change.

Read our rules on project management for some simple tips before starting your next project.

Adam Cogan, SSW Chief Architect

: Figure: Classic stories of Project Management

SSW's Rules to Better Project Management, (otherwise known as XPDM) built on eXtreme Programming, allows businesses to address their most important challenges first, and respond quickly to change. Our rules advocate software consultants working on-site, or on the phone, so long as there is close consultation with business users, with the goal to become integrated members of the clients team.

Indicates important rule

Rules to Better Project Management

Do you conduct a Specification Review?
Do you create an Initial Release Plan and Ballpark?
Do you conduct an architecture and code review after every release?
Do you effectively present the outcomes of the Specification Review?
Do you obtain approval for the Initial Release Plan and Ballpark?
Do you do schedule further specifications?
Do you create a detailed release plan and get it approved?
Do you know how to estimate a Release?
Does your project manager maintain a strict project schedule?
Handover, support and warranty

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 $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.

"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 (around $200,000) 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.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/SpecificationReview.aspx
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
1. Release 1 (1.5 man months) - Specification (mock up screens, customer stories/business rules) (Releases 2 - 4)
2. Release 2 (1.5 man months) - Database schema design
3. Release 3 (1.5 man months) - Development Module 1 Customers
4. Release 4 (1.5 man months) - Development Module 2 Products
5. Release 5 (1.5 man months) - Specification (mock up screens, customer stories/business rules) (Releases 6 - 8)
6. Release 6 (1.5 man months) - Development Module 3 Orders
7. Release 7 (1.5 man months) - Development Module 4 Suppliers
8. 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.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/InitialReleasePlanandBallpark.aspx
Do you conduct an architecture and code review after 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 4 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
- User experience
- Network
- Responsibilities/players
- Infrastructure
  - Network
  - Hardware
- Deployment
  - Staged implementation
  - In parallel
  - Development/Test/Staging/Production
- Disaster recovery
- Change control/source control
- Build Server
- Performance
- Scalability
- Extensibility
- Design patterns
- Maintainability
- Reliability (failover servers?)
- 'Sellability' i.e. is the solution appropriate for the client?
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/ArchitectureCodeReview.aspx
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.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/SpecificationReviewPresentation.aspx
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.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/ApprovalInitialReleasePlan.aspx
Do you do schedule further specifications?

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 specification time in every release.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/ScheduleFurtherSpecifications.aspx
Do you create a detailed release plan and get it approved?

SSW develops software in Releases. A Release is a detailed task list of work items. A Release is a maximum 2 weeks duration a maximum of 160 hours. The work items are a breakdown of all the tasks required to be performed in that release (including all the specs, forms, mock up screens, and the business rules/customer stories related to those tasks.

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). The more frequently we delivery releases publicly the better the application will be.

To physically create release plans at SSW we use TFS (preferred) or SSW eXtreme Emails!. This makes constructing a release plan as easy as clicking a button!
1. Creating release plans with TFS Work Items
  - Sample TFS Release Plan
2. Creating release plans with Extreme Emails
  - Sample Extreme Emails Release Plan
Note: Why don't we use Microsoft Project because of the following problems:
- Tasks are auto scheduled based on dependency and resource allocation (who is assigned to it). This generates an estimated completion date which is never accurate, due to annual leave, public holidays and general shuffling of people in the team (e.g Urgent fix for an old client for ½ day).
- It gets the summing wrong (the totals don't seem to update and no way to trigger it)
- It's hard to synchronize with timesheets (as it doesn't connect to 3rd party timesheet systems out of the box – however, it does have its own time sheeting system, that is missing billing information!)
- You cannot allocate two people to a task. This create a lot of additional overhead to get it right. **fixed in TFS 2008**
Mockups - One of the first thing to agree with the customer is the mockup. SSW offers four options for mockups.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/DetailedReleasePlan.aspx
Do you know how to estimate a Release (that include the ‘General Project Costs’)?

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:
- Further specification: 20%
- 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 (NOTE: this is an Excel template file and only works in Firefox (!) and you Save the File (don't "Open" it) and then open the file in Windows Explorer!)

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 unauthorized scope development.

Note: It would be great if TFS Web Access had functionality “Add Standard Items to a Iteration (aka Sprint, Release etc.)”
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/DetailedReleasePlan.aspx

Does your project manager maintain a strict project schedule?

It's been called 'herding cats'. Managing the project team and keeping the client well informed during the release development phase is critical. Keeping development of the release on track involves maintaining transparency on the important variables of project management: time, scope, budget and quality. This is achieved by maintaining a strict project schedule with particular activities taking place regularly like clock-work.

Some activities are run internally while some are run with the client.E.g.,

Day	Internal activity	External activity
Monday	Stand Up meeting (or Scrum) Management Reporting Build review

Tuesday	Stand Up meeting (or Scrum)	Conduct a test please with the client Triage additional item requests Obtain approval for additional items and budget overuns Release update/debrief Release sign-off Release deployment Next Release approved

Wednesday	Stand Up meeting (or Scrum)

Thursday	Stand Up meeting (or Scrum) Architecture/code review

Friday	Stand Up meeting (or Scrum) Internal build Test please

: Figure: Only with a strict project schedule can the manager coach the team to success!

*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToBetterProjectManagement/Pages/MaintainStrictProjectSchedule.aspx

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.

e.g. As per our conversation, this work has not yet been tested and may still include bugs. At this stage you would prefer if we did not continue work tomorrow, but I do recommend that we come in and finish soon.
*Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/Management/RulesToBetterProjectManagement/Pages/HandoverAndWarranty.aspx