Services Offered

Your Priorities

The preparatory work done before selecting a software development vendor, and the monitoring and management of your selected vendor during system implementation and release, are both important, and the services that I offer cover both of these phases of a project.

The time where my technical experience and knowledge is likely to be of most help, however, is when identifying, interviewing, and finally selecting the vendor that will build your system. The particular areas where I can provide help with this phase of a project are summarized to the right under 'Vendor Selection'.

If your budget limits how much of my time you can secure, focusing on the 'Vendor Selection' topics is likely to give you the most bang for your buck.

Do I Write Software for Clients?

Typically no. Under certain circumstances, however, I will undertake to build systems for clients, using a small, hand-picked team of experienced developers. If you would like to discuss the possibility of us building software for your business, give me a call.

What I Do Not Do

My skills and experience are in custom software development - that is my only professional field. I do not offer services related to:

• Email
• Networking
• System Administration
• Data management
• Disaster recovery
• General IT consultancy
• Hardware of any sort

Pre-Vendor Selection

The services that I offer, prior to the selection of a software development vendor to build your system, include the following:

Project Planning

• Clarifying hosting requirements & options
  • Should you host your system yourself, or have the vendor host it, or use a third-party hosting service?
• Minimizing vendor dependence
  • Your ability to independently re-build your own system from the source code if your software vendor goes AWOL.
  • Avoidance of any vendor-specific technologies.
  • Clarification of any license or distribution issues.
• Helping to create the Functional Specification.
  • The critical distinction between 'Must Have' and 'Nice to Have' features.
  • How to avoid 'feature-creep' - the primary reason for software systems being delivered late.
  • Timeline estimations.
  The clearer the specification, the less chance there is of a misunderstanding causing later problems.
• Helping to create a project outline to present to candidates.

Project Structure Recommendations

• Definition of an initial Proof-of-Concept
  • A simple, working deliverable from the vendor can test their claims of code quality very early in the project life-cycle.
• Incremental Releases
  • Question: How does a software development project get to be six months behind schedule? Answer: One day at a time. I can help you avoid this happening.
  • Software developers do not always refer to the Functional Specification document when writing code. The longer that your chosen software vendor works without you seeing the result, the greater the risk of them building something that is not what you need. The best way to avoid this happening is to agree to have regular, incremental releases which you can view and test yourself.
• Milestones with source code delivery
  • There should be clearly defined 'milestones' during the development process, where for each an assessment is made to determine whether the project is on-track, and if not, to work out why. If the payment structure of the business relationship with the vendor allows it, the source code written for the system to-date should be delivered to you at each milestone.
    This protects you from a situation where the vendor suffers some catastrophe and cannot operate, or their key personnel leave the company taking all knowledge of your system with them, or if you are unhappy with their performance and want to switch to a different vendor.

Intellectual Property (IP) & Source Code ownership

• Vendor switching
  • If after your completed system has been delivered, you decide to end your relationship with the vendor that built it, it is vital that you have all the system's source code, so that further enhancements to the systems can be implemented, and any bugs found and fixed.
• Disaster recovery
  • Similarly, if the hosting platform where your system is running has a catastrophic failure, you need to be able to re-deploy the system to an alternative platform, which may imply having to rebuild it from the original source code.
• Either way, it is critically important to ensure that a) you have access to all of the source code used to build the system, and b) you own all of the IP for the code, so that you are free to modify and distribute it as you need.

Vendor Selection

If you contract a low-quality software development vendor to build your system, the project may fail as a result. The most important services that I offer are those listed here, designed to minimize the possibility of this happening.

Identifying Candidates

• Clarify geographical factors
  • communication across different time zones
  • the need for face-to-face meetings
• Search for possible candidates
  • Required technical expertise
  • Required business experience
• Review and follow up on references
• Produce a short-list of candidates
• Schedule the first Vendor Call for each short-listed candidate.

Vendor Calls - I can be present during vendor selection calls, or provide you with pre- and post-call support - whichever you prefer. Either way, if possible these calls should be recorded, so that verbal commitments and claims can be subsequently confirmed. An architect-level representative from the candidate company needs to be present on the calls, and must be willing to commit to be personally involved during the entire project.

First Call - High-level Topics

The first vendor call would be discursive, covering some of the following areas:

• Present a recap of the high-level project deliverables
• Establish clear points of vendor contact (PMs, Architects, Team Leads, Developers)
• Clarify preferred platforms & technologies
• Discuss vendor's philosophy for software architecture
  • Modularity of different components
  • Centralization of common logic/code
  • Choice of database
• Understand vendor's development environment
  • source code control
  • management of database schema changes
  • security for offsite workers
• Review vendor's coding standards, including code comments and external documentation
• Discuss and clarify IP/code ownership
  • Code transfer on milestone payments
• Confirm willingness to produce 'proof-of-concept' to backup claims of technical quality (see below)

Second Call - More Technical Depth

If the first call goes well, a second call will be scheduled to go into more technical detail:

• Problem-solving
  • Solicit input about examples of the vendor addressing real technical issues/requirements
• Database design
  • For a system whose data is stored in a database, the database itself is the 'heart' of the system, and the correctness of the design (the 'schema') is critically important. If the schema is wrong, it will be difficult - if not impossible - to ever write efficient code against it.
  • Client involvement - irrespective of your own technical knowledge, if the database schema is not understandable to you, it is probably wrong.
  • Normalization v Performance - how to balance the two.
• Technical expertise
  • Approach to error and exception handling
  • Ask specific technical questions about problems solved
• Ability to quickly illustrate UI concepts with private releases
• Testing Strategy
  • What is the vendor's testing strategy? For example, do they adopt a formal regression test of the entire system before deploying a new version into production?
  • Is there a dedicated testing team, whose goal is to stress-test the software to the point of trying to break it? It is not sufficient to leave all the testing to the developers that write the code - all too often they will only test scenarios that they thought of themselves, and catered for in their code.
• Willingness to deviate from original specification if requirements change
• Bug tracking and Release strategy
  • How are bugs reported, and what is the process of ensuring that they are fixed?
  • If a show-stopper bug is discovered in a production system, how to identify which release introduced it
  • How is the system 'rolled back' to an earlier release?

'Proof-of-Concept'

Ask the vendor to agree to build a simple 'proof-of-concept' application, as a demonstration of their ability to back up their claims of code quality by writing high quality code.

• The proof-of-concept should implement a simple task related from the functional specification, so it won't be wasted work
• I will evaluate the quality of the design, code and documentation for the proof-of-concept
• Any concerns raised by evaluation should be discussed on a call with an architect/senior-level developer from the vendor

Finally, I will make a recommendation of which of the candidate vendors to select.

Post-Vendor Selection - System Implementation & Release

Congratulations! You've selected a software development vendor that has demonstrated their ability to understand your business goals, and to build, test and release the system that you need to achieve these goals. The difficult part has been done, so why else might you need any help from me?

• Review of database schema
  • The database is the heart of a data-driven system, and its design (the 'schema') is critically important to its overall operation. If the database schema does not accurately model the business world of the client that it is intended to support, operational problems will almost certainly occur. Prior to starting the software writing phase of a project the schema should be carefully assessed to make absolutely sure that it is correct, and if there are errors or omissions they should be addressed before any coding starts.
    Based on an understand of the client's business model I will be able to confirm whether or not the database schema does accurately reflect this model. And based on the planned functionality of the system I will be able to identify any potential performance bottlenecks in the schema.
     
• Weekly Status Updates
  • A software vendor's Project Manager (PM) keeps track of the progress of projects, continually working with the development team to make sure that a development effort remains on track. Without this scrutiny projects can start to slip, falling further and further behind schedule. At the start of a project the PM should create and share with the client a project timeline - a chronologically ordered series of milestones during the development process - to be used during the project to confirm project progress.
    There should be weekly status meetings between the client and the PM, where, based on the project timeline, it is determined whether or not the project is progressing as per the planned schedule, and if not, to quantify and track the slippage. If a project is slipping further and further behind schedule, it is important to understand why, and to rectify the problem as soon as possible.
    Claims of project progress should be backed up by both interim releases where functionality can be seen to be working, and presentations of the completed code that supports the functionality. I will be able to confirm that the presented code is indeed complete and production-ready.
     
• Regular Code Reviews
  • Having committed to write high quality code, a software vendor should of course follow through on this commitment, ensuring that all code written conforms to the promised level of quality. Policing the quality of work done by a team of developers, however, is difficult. It can be tempting, too, to move more senior developers to new projects, introducing less experienced staff into an existing project team, which can lower the quality of code being written.
    When a development team is under time pressure, there is a higher risk of code quality suffering as a result of shortcuts being taken, or code being released without the necessary testing.
    By periodically reviewing the code written by the development team I will be able to spot any deterioration in quality, and raise this as a concern, before it becomes a problem.
     
• Bug reporting/tracking
  • All software development companies need a formalized, centralized repository for reporting and tracking the bugs discovered during the development and post-release operation of a software system. There is no reason why such a system should not be made available to the client paying for the system. Indeed, there should always be an option for bugs that are discovered by the client themselves to be entered into the bug reporting system.
    By periodically reviewing the process of bugs being discovered and fixed, I can identify areas within the code-base which seem particularly prone to bugs. This in turn may indicate more fundamental flaws in the design of the underlying logic, which need to be addressed.