SSW Rules to Managing Software Consultants

1. 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 then anyone else. Bottom line is he watches what their 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. 

2. Provide a Company Champion

   There are lots of stakeholders in a software project. Users, Marketing, Managers, IT all have requirements for the new system. The more the spec becomes a free-for-all, the more likely the project is to get steered off-course.

   Provide one individual - we call this person the 'Company Champion' - who is able to make business decisions and authorise work. This person is the key contact for the project and all enquiries (phone and email) are to be channelled through this point.

   Once you have established who the company champion is you must stick to them for approving future work. It's all too tempting to go ahead with work that the DBA asked you to do, without getting proper authority. The right way to get this approval is:

   • To receive an email from the DBA with the company champion cc’d
   • To send yourself an email and cc the company champion

3. Be Specific in your Requirements

   When your 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.

   The best way for this to work is to break tasks into the smallest possible 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 mightnt 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!

4. Read 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.

   SSW Rules to Better Email

5. Determine whether a Fixed-Price or Variable contract is the most suitable

   There are both plus and minus factors to consider when deciding to take either a Fixed-Price or Variable contract for Software Development.

   A fixed price is only offered when the work has a fixed-scope. This means that you have a precise specification of what the software is meant to do. Getting this together is sometimes extremely hard, especially when the project is conceivably large. New ideas for functionality can be excluded as the work falls out of scope, and problems occur if aspects of the business model change through-out the course of development. The benefits of rapid development are lost as each minor change requires authorisation and approval.

   Generally speaking you will have to pay a premium loading on top of any estimate when engaging in a fixed-price. This allows for the possibility that the developers have underestimated the work involved. Of course, the converse is true. If the developers have over-estimated the work involved, you may end up paying more than you should have.

   On the other side, a variable rate contract can spin out of control as scope continues to grow without any scope management in place. In addition, there is the risk that coding commences too early before the architecture is sorted resulting in excessive re-engineering.

   So the rule is: If the scope if fixed, go fixed-price. If the scope isn't fixed, go variable.

   In reality, the choice between fixed-price or variable estimates is not that important. It's more important to ensure the work is broken into the smallest possible pieces. If it's a $100,000 job, break it into 5 x $20,000 Releases. This way it's not an 'all or nothing' approach, and both parties have the ability to review any problems.

6. 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 Company Champion should be able to answer developers questions within 4 hours. Otherwise decisions are delayed and costs are increased.

7. Conduct User Testing

   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.

8. 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 are 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?

9. Be Aware Changes Impact on Time and Budget

   Often towards the end of a project, you may request extra pieces of functionality ("Can you add a second email address field into the ClientContact 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.'

10. Be 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.

11. Understand Deadlines often Move

    If you have a tight schedule and deadline for release we need you to be clear with your developers right at the beginning what needs to be done 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 to short or too long. It is very hard to be 100% accurate when estimating hours to complete work..

12. Sign the consultants timesheets

    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.

13. Watch the Project Costs

    Determine the process for invoicing and payment as part of the project plan. Nothing beats regular weekly invoicing to ensure everybody knows how much development is costing. During the heat of implementation both sides can get slack on the invoicing and payment side of things. If either side feels a bit out of the loop, then it's important to 'stop' until it is sorted out.

14. Do you send a warning email to project manager?

    An email is to be sent when the release is at 40%, 80% and 100% of the budget
    We require Email that says "we have just hit 40% of the budget, you are tracking behind because you have only completed 31% of the release".

15. Do you want a project manager on your project?

    Our clients have an option to use a project manager on their projects. When A project manager will work about 3 days on the project and they will never write code.

    Project managers should look after 3 things: Score, Budget and Time.
    • Helping to make sure the customer is informed of budget overruns and technical issues and given the earliest possible opportunity to:
      1. stop the project
      2. remove tasks
      3. reassign tasks to cheaper resources (e.g. China)
      4. Reassign the tasks to more effective resources
      This is assisted by generating Timing, ETAs and financial reports that developers don't normally generate:
      1. Financial Reporting e.g. using Microsoft Project to show baseline estimates against actual figures and predict problems and deadlines
      2. Updating TimePRO projects and the project status and sending out the Project Progress report
    • Keeping a close eye on developers/team leaders to see if there are any problems that have simpler solutions or would be better done by an expert/outside resource or using a 3rd party tool
    • Helping to make sure that the ongoing quality of the product is good standards are enforced. E.g.
      1. Identify opportunities for automated testing and unit tests.
      2. Running code auditor/SQL auditor/FXCop.
      3. The most effective tools are used such as using code generators for repetitive work.
      4. Suggesting refactoring possibilities if there is repetitive code.
    • Helping to Removing any client-side or developer-side bottlenecks to development (e.g. following up questions that the client is not answering/developers just waiting on response or are stuck with a product bug or coding issue)
    • Helping developers to determine what should go into the current release and what should go later (scoping ¨C ie what is in scope/out of scope)
    • Updating the scope documents (this is not done in normal projects; we typically create the document and leave it to gather dust)

16. What updates does SSW provide to clients?

    Things that you can ask are:
    1. How much we have spent
       

       
       Figure: project progress report.

    2. How much to go
       

       
       Figure: project update report.

Acknowledgements

Cameron Shaw
Adam Cogan

All work is performed according to our standard Consulting Order Terms & Conditions.