A Partner for Your Custom Software Solution – pt 2: Determine Your Level of In-House Expertise
From “Part 1: Identify the type of project” you should have a clear idea of the project you want, and what’s needed to accomplish it. Now it’s time to take a look at yourself and your team. A clear analysis of the expertise and experience you have in-house can help you determine the responsibilities you want to delegate to a partner.
Determine your level of digital realism
Building software is not the same as building a house. A digital project is quite different from any offline project and follows its own rules. ‘Digital realism’ is the mindset of knowing and understanding these rules.
You don’t (always) know what you want
Starting out, you might have a clear idea in your head of what the finished product must look like. Don’t just try and build that imaginary product. What you will learn along the way by scoping and testing the product increments is going to be key. You will end up with a much clearer picture of the product you really need. Having a vision is not a bad thing, just make sure you can adapt it to the reality of the situation.
It’s hard to work agile on a fixed price
Agile contracts capture an agreement in broad strokes, but don’t mention too much detail. This allows any insight gained during development and testing to be implemented within the confines of the contract. If you work with a fixed price, anything clarified, crystallised or dreamt up after the contract was signed, will be treated as a change request. We suggest working with a price range or with a fixed price, flexible scope approach.
Learn to prioritise and compromise
Start from what your product absolutely has to do and get that working the way you want to. Once you have that, leftover time and money can be used to add the things you want (but don’t need) it to do. This means it is imperative that you are able to prioritize correctly, and compromise when needed.
More developers does not mean faster delivery
Simply throwing twice the people at a project does not (necessarily) mean it will be completed twice as fast. Expanding a team past an optimum size will not bring the cycle time down any lower and could even do the opposite. On very large projects, however, it might be beneficial to break the project up and expand the number of teams. Think of it like this: one woman can create a baby in nine months’ time; nine women can’t create a baby in one month.
Accept that all software developers write bugs
No software product is ever completely bug-free. First builds will have a noticeable number of bugs. Allocating sufficient time for testing will significantly reduce this number. But that number will never be zero.
Determine your level of execution expertise
Digital realism is about the mindset, execution expertise about getting the work done. There are different kinds of work to be done of course, as digital projects are more than just development. Aspects like analysis, wire-framing, design, testing, project management, SEO, etc. are all important in creating a viable digital product. It’s perfectly fine to only outsource those parts of the process you’re not comfortable with. However, this means that you must have a realistic picture of the skills already present in your company, which can be harder than it sounds. A good understanding of what each aspect entails and a critical eye to look at the skills you have, are indispensable.
A good understanding of what each aspect entails and a critical eye to look at the skills you have, are indispensable.
How does this affect your selection of a partner?
Taking digital realism and execution experience together, there are roughly three possible scenarios.
No digital realism and little to no execution experience: offload your project
In this case, you have to put a lot of trust in your partner, but in return you don’t need to put as much time into the project and, conversely, don’t need too much know-how. It’s not necessary to offload the entire project; you can offload only those parts you don’t have the skills or manpower for, while doing other aspects yourself.
Digital realism, little to no execution experience: partnering, or keeping the reins
This scenario requires a greater time investment than offloading, and also hinges on a personal match with your software partner, since you’ll be working together much more closely. You might work together as partners, or you could keep the reins firmly in hand, but realize that the latter requires more know-how and puts greater responsibilities on your shoulders. Either way, it will be easier to course correct along the way, and it’s a great way to acquire (further) execution experience.
Digital realism and full execution experience: do it yourself!
If you have all the necessary know-how in-house, it might be a good idea to develop your project on your own. This does require manpower, of course, so if that’s not something you’re willing to invest in, or you want a time-to-market that is not possible with new hires or consultants, partnering up could still be the way to go.
What about your business expertise?
The importance of business expertise for your project depends on the type of project. A simple marketing site for some online presence is a totally different beast than a business-critical system that underpins your entire organisation. Your business expertise has value in both cases, but it is essential for projects with high strategic importance and functional complexity. Your input is absolutely required, not only for initial planning and analysis, but throughout the entire project.
Start-ups are sometimes an exception to this rule, because they often do a project of high strategic importance, without necessarily having a ton of business expertise yet. In these cases, we advise to select a partner with experience in related business areas, to collaborate closely with them and to develop your product incrementally, keeping the time-to-market short for each iteration. This way, you can learn a lot in a short amount of time and quickly go from an idea to a minimal viable product.
What if this is your organisation’s first digital project?
If you’re new to digital projects, you must start somewhere, and that somewhere is on small projects. As you’ve read, we advocate offloading if you have no digital experience. However, offloading will not teach you that much, so ask yourself whether you want to do more projects in the future. If the answer is yes, then take a leap and find a partner who is willing to show you the ropes while working together.
But please, do yourself a favour and start small. Learn the different stages of a digital project and what they require, learn the ebb and flow of design, development and testing. And once you have these basics down, then you can start thinking about larger and more complex projects. Because jumping into large, strategically important projects without digital realism is like jumping in the deep end of the pool without knowing how to swim: you might stay afloat, but it won’t be elegant, and you probably won’t move in the direction you want.
In conclusion
Before embarking on a digital project, it’s important to asses and map your in-house knowledge and execution capabilities. The motto here is ‘Know Thyself’. If you’re unsure whether you’re ready for the big leagues, or sure that you’re not, start small and learn as much as you can from your software partner.
We’ve already touched lightly on the different ways of working together, but in the next post, we’ll expand upon that and look at different ways you can work with a software developer.
An overview of our series, “A Partner for Your Custom Software Solution”, you can find here.
| Published on Java Code Geeks with permission by Jan Nuyens, partner at our JCG program. See the original article here: A Partner for Your Custom Software Solution – pt 2: Determine Your Level of In-House Expertise Opinions expressed by Java Code Geeks contributors are their own. |
