SSW Rules to Managing Software Consultants

Do you know what is going on?

We've all heard horror stories of tradesmen causing chaos: "I asked them to fix a tap, but after the sink broke we had to move out for 6 weeks while the carpet was dry-cleaned and new floor-boards were laid." This problem generally occurs after you have let the supplier have a free-for-all in your house while you're at work: "Just let yourself in, the keys under the mat, and get the job done".

My Father-in-Law is Greek and I have noticed he gets more out of a tradesman than anyone else. Bottom line is he watches what they're doing and then gets on their case early when things aren't perfect. Whether it's carpet layers not matching the patterns together or plasterers leaving unsightly corners - as soon as he spots a problem he confronts them straight away and gets them to rectify it.

With any professional consultant or tradesman you should always take a hands-on approach with the project, stay on top of the important issues, and be ready to get involved when you see a problem.

Of course, as your relationship builds with the consultant or tradesman, and they become more aware of your expectations, you can divulge greater trust and leave them to it.

So insist your software consultants maintain verbal contact with you.

Do you provide a Product Owner?

There are lots of stakeholders in a software project. Users, Marketing, Managers, they all have requirements for the new system but if the spec becomes a free-for-all, it is more likely the project will be steered off-course.

Select a "Product Owner" - who is the sole person able to make scope decisions and authorize work.

Remember it's all too tempting to allow the DBA to authorise work without seeking proper authority, so insist that your software consultants follow the standard on getting work approved through a Product Owner.

Are you specific in your requirements?

When you're scoping the work to be completed, ensure you are as accurate as possible in your requirements. Saying "I want to keep contact details on my clients" is likely to require later clarification. Instead say: "I want to record my clients' firstname, surname, mobile phone, email address & Instant Messenger messenger address." This way, you'll get exactly what you want. Even better, use screen shots or mock-ups.

The best way for this to work is to break tasks into the smallest possible bit size pieces and ensure that those pieces are in the project plan explicitly.

Sometimes software developers miss a related item which you might consider 'blindingly obvious.' For example you might ask them to fix a combo box on one form in a legacy application. But they mightn't know about the three other forms that the same type of combo appears on. So if you also want them fixed, then let them know about them!

Insist your software consultants conduct specifications by creating mock-ups.

Do you read and manage your emails carefully?

Email has a bad name in business primarily because people don't treat email correctly. Email can be a vital tool to your company, and your software development project, but it has to be managed. Email should be an accurate record of requests, conversations, and decisions. Emails are legal documents and should be treated with the same care as any other correspondence with clients or employees. Email is also an extremely effective task tracking tool, and requests made by email should be treated with the same seriousness as Project Plans and other directives.

Software developers send many queries via email, we ask that you pay close attention to your Inbox and respond promptly.

Insist your software consultants follow the standards to better email

Do you respond to queries quickly?

Now we're working, you'll get loads of questions. Most software projects demands close interaction with the Client. As the developers are usually working to tight budgets and schedules, getting quick answers to questions is a must. The Product Owner should be able to answer developer's questions within 4 hours. Otherwise decisions will be delayed and costs increase.

A good way to fix this problem is to insist your software consultants contact you via MSN/Live Messenger.

Do you conduct user acceptance testing thoroughly?

The shorter the time period between development and testing, the quicker it will be to solve them. When your developers get you a test version, have your resources available to review the version and get feedback to them straight away.

Insist your software consultants run a test please with you every week.

Do you know who pays for 'bugs'?

You WILL discover bugs in any newly developed software. This is perfectly normal. It's important to have a common understanding with your software developers about what to do when they arise.

'Bugs' are generally a consequence of the development team not knowing every possible scenario when adding error handling. Generally speaking it takes developers just as long to add the error handling before you test it than after you test it. Bugs can also occur when development requirements change on the spot or work is not sufficiently specified.

For these reasons, fixing such issues is generally billable work on time & material contracts. On fixed-price contracts, bugs are generally fixable within the warranty period at no cost to you.

What is a bug?

Do you remember any changes you request will impact on budget and time?

Often towards the end of a project, you may request extra pieces of functionality ("Can you add a second email address field into the Client Contact form?"), or maybe another report is required. Even in the middle of a project extra work can be requested as project goals move. So long as there isn't a technical or business problem with the request, the work will be scheduled by the developers and done.

Every new item that is requested increases the total hours and scope of the project and therefore the cost. If the project has a drop-dead date or budget, don't ask for things that will blow these deadlines out. Or, if you want your developers to work to a budget, ask them to let you know what 'can't be done.'

Insist your software consultants correctly triage additional item requests.

Are you aware of existing issues?

No doubt there will be a time when you get new developers to work on an existing application. Known issues with the existing application should be clearly delineated as much as possible. But new bugs will occur when changes have unforeseen effects on functionality down the line. This is to be expected.

Once again it's a matter of working with your developers in being clear in requirements and testing as changes are made to ensure these issues are trapped as early as possible.

Ask your SSW developer to add a test case which will mean in the future important functionality will never "disappear" or break.

Do you understand deadlines often move or scope has to change?

If you have a tight schedule and deadline for the release, we need you to be clear with your developers right at the beginning about what needs to be done and when. Most developers generally can't guarantee they can work with your deadlines, but they'll be honest up front about when items can be completed.

Your budget and deadline may mean some items will not get done.

Sometimes their estimate on items are way too short or too long. It is very hard to be 100% accurate when estimating hours to complete work.

The best way to keep track is to insist on a weekly release update/debrief.

Do you sign the consultants timesheets every day?

Many software developers will work on-site, especially on time & material contracts. Before they leave your offices every day, ask them to present their diary, or whatever method they use for recording time, for checking and signing. This way, you can see what was done and raise any issues with developers.

Insist your software consultants ask you to sign their timesheets every day.

Do you use an experienced project manager or a Scrum Team?

Some clients think that a Project Manager is just a resource that increases the cost of a project. But a house does not get built if you leave the architect, carpenters, electricians and plumbers to just work it out between themselves. The house DOES get built if the foreman is keeping everyone on their toes making sure they are doing their job.

Insist your Project Manager maintains a strict project schedule.

Do you get regular updates on costs and progress?

You're the one paying the bills, make sure you know where the costs are and how the project is progressing.

Insist on receiving the following reports on a weekly basis as a minimum:

• Current project costs (from the timesheets directly). This allows you to see the actual costs of the project on a weekly basis.

  
  Figure: Project Progress report

• Current hours remaining and hours completed for the current sprint:

  
  Figure: Burndown report showing the progress of the team in the current sprint

  Questions the Burndown and Burn Rate report helps answer:

  1. Is the team likely to finish the iteration on time?
  2. Will the team complete the required work, based on the current Burn Rate?
  3. Has the team added work to the iteration?
  4. How much work does each team member have?

  How to Use the Burndown and Burn Rate Report

  
  Figure: Stories report showing the progress of the User Stories in the current sprint

  Questions the Stories Overview report helps answer:

  1. How much work does each story require?
  2. How much work has the team completed for each story?
  3. Are the tests for each story passing?
  4. How many active bugs does each story have?

  How to Use the Stories Overview Report

• What has been completed and what is outstanding (from the Release Plan Work Item list). This allows you to see the actual progress of the Release.

  
  

  Bad example: Release Plan update using eXtremeEmail not TFS

  
  

  Good example: Release Plan update using TFS

If you need more than this you just need to ask your project manager (but be aware that extra reporting costs time)