* We provide a free guide for software project administrators.
Project Plan Review
You have a software-oriented project plan which looks great on paper - but how will it perform in the wild? Are you confident you are up to date with the rapidly changing software ecosystem, and understand how your app will fit into it? Have you assessed your project from a technical perspective as well as a business one?
Why not have your plan examined by seasoned coders with many years experience bringing new software to market? In our Project Plan Review we will provide a professional opinion on the potential for your proposed software application. We will gauge the effects of demand and competition on its chances in the marketplace, as well as identifying the factors that are most likely to prove challenging. We will also assess feasibility from a technical perspective, and provide guidance on projected development costs.
Software projects are complex, and can be difficult to understand; there are a wide variety of ways they can fail to live up to expectations - or indeed fail completely. Getting sound advice early on could save you significant costs and headaches going down wrong roads, or even make the difference between crashing out early versus stablising a successful business model. The costs of an early review are negligible compared with the huge potential benefits.
Spec Development
If you browse our software development guide you'll note that we rank having "no clear spec document" as one of the top 10 mistakes made when embarking on a software project. Put simply, this is because you can't trust developers to guess what you want building. Nor can you take any quotes for development work seriously because the quote came from someone's imagination, and not from anything tangible. Yes they will quote - but later you'll have arguments.
This is why, once you have decided how your project will work from a business perspective, the next step should be to create a spec. This does not need to be an exhaustive document detailing every step of your project in advance; in fact generally we would recommend planning only the next phase of development. When starting from scratch, this is usually the spec for an "MVP" (or "Minimum Viable Product") which will carefully describe the simplest set of features that still comprise a fully-functional app meeting user expectations.
The careful decision making that goes into creating a spec is also likely to save you considerable time and money - and quickly pay for itself. You are forced to identify exactly which features to include and which to leave out - and this results in high efficiency during the development process. You'll have a far better understanding of your own project, and dramatically reduce the possibility of expensive wrong roads.
If that all makes sense but you are struggling to imagine where to begin, then our Spec Development service could take the weight off your shoulders. We will work with you to produce a comprehensive document that will put everyone on the same page - with no obligation to take any further services with us.
Technical Review
There are many situation where it makes sense to get an independent technical review of an existing system. Some examples are:
- As a reassurance measure to make sure your current development team are following good development practices - and are not cutting corners;
- To obtain independent recommendations for improvements and optimisations;
- To assess the risks inherent in a system due to architecture choices and/or the presence of technical debt;
- When reigniting development on a project which has not been enhanced for some time. What are the catches going to be with extending the system?
Our diagnostic reviews generally cover all technical aspects that relate to engineering quality - from the choice of technologies down to the design of individual code units. However, after discussing your project with you we will tailor our analysis and report to match your specific objectives. While our technical reviews certainly contain technical information, all reviews are intended to be understandable for non-technical readers.
We offer 4 levels of technical review:
User Experience
This simple review provides an independent quality control assessment of your web or mobile application from the perspective of a tech-savvy user. Does your app follow the conventions users will expect? Is the interactivity confusing, or is it intuitive? We will browse your application noting UX/UI properties such as link, button and form behaviour, notifications and messaging, loading speeds and overall UX/UI design. Note that this is the only review type we offer which does not require inspection of the codebase.
System Overview
This level of review is geared towards providing recommendations on the scale of the component packages, libraries and frameworks which comprise your application. Can alternative configurations, technologies or tools be identified that would result in more efficient operation? What overheads would be involved in making the changes, and how quickly would improvements recoup development costs? A comprehensive breakdown of the available routes to higher efficiency is included in our final report.
Code Inspection
In addition to a system-level overview (see "System Overview" above), this more detailed review includes an assessment of code organisation and quality. We will aim to present samples from your codebase which constitute the greatest departure from good development practices, alongside an explanation of the issues identified. We will also provide insight into the general severity and prevalence of technical debt across your application, its effect on efficiency - and the best options available for reducing it.
Component Testing
The most in-depth of our techical reviews, Component Testing includes the analysis performed in our Code Inspection review, but adds in results gathered from actively testing selected areas of your codebase. This type of review is most appropriate in cases where specific issues are known or suspected to be present, and this information will be used to decide which tests to perform. Test results will then be interpreted in the report, and used to provide suggested resolutions and a breakdown of the associated overheads.
How (Not) to Run a Software Development Project
The top 10 most common noob mistakes - so you can avoid them.
Q. Who is this list for?
A. Anyone setting out to run a software project, including:
- individuals taking the plunge with their first app
- bootstrapped and/or investor-funded startups
- new project managers taking the reins in an established company
- anyone else looking for more insight and tips for managing a software project
Q. Why do I need this? I know what I’m doing!
A. Are you sure? Evidence suggests you probably *think* you know what you are doing - while the most likely reality is that you actually don’t!
Ouch! Did that hurt? But I’m not trying to offend. It’s just a simple statement of fact, based on the following 2 observations:
- The vast majority of software development projects don’t even make it to market, let alone generate any revenue. You can verify this fact for yourself by searching for something like “percentage of software development projects that fail”. And when you hit on a Forbes article claiming that number is 85%, just remember the business media generally refers to well-funded projects built by established companies. In my opinion if we include shoestring-budget projects and bootstrapped startups that figure shoots into the upper nineties. We really are talking about almost all projects. Based on statistics alone, your project is almost certain to fail. The first step in defying these odds is accepting this is the position you are starting from.
- As an independent contractor often invited onto stalled or partially finished projects, I have personally witnessed these failures firsthand. Time and time again. Over many years. I can tell you that the vast majority of failures are for *exactly* the same reasons. The same mistakes repeated in an endless loop. Software development Groundhog Day. And in every single one of those cases, the project leader thought they knew what they were doing. (If they didn’t think they knew what they were doing, they might have done some research - and perhaps not made those exact same errors.)
Q. You got me! So, what’s on the list?
A. Download to find out!
