(a followup to discussion last week)
In every outsourced software project you have four large areas: your customer, the business vertical you are writing software for, your implementation team and the technology foundation or platform you are using.
Two of these areas are on "internal" side of your organization (team and technology), two of them are on external - your customer side (business domain and customer organization). Two are more micro level in the sense that they have strong human interaction aspect (customer and team) and two are more macrolevel and less personal (business domain and technology). For that reason, you can represent these areas as quadrants using two axis micro/macro and internal/external: micro+internal = team, micro+external = customer, macro+internal = platform, macro+external = business domain.The degree of risk in the project is proportional to how many of these quadrants are actually unknown or new. Why is that ?
Having a new customer, you do not have established the communication channels, the degree of trust based on past successes is not there. You do not know the customer's corporate culture, internal structure, relations, influencers and inner politics that in theory should be completely irrelevant, but in reality may be one of the most disruptive discoveries. As one wise man said "It is usually politics that gets you into troubles, very seldom technology".
Starting project with new, untested team, the team lead does not know what would be the best work division between the developers. Eventually, it can be discovered over time, but reshuffling the position has disruptive effect and usually requires some rework or refactoring. It is also very hard to make estimates as the team members productivity is unknown and does depend on the task.
Switching to new technology, obviously, you will have to incorporate some learning period and count on initial slowdown until everybody is as proficient in "the new great thing" as well as they were in the "old boring one" :-). This can be planned for and incoporated into project plan - or ideally, fixed before the project start on a prototype-slash-pilot project. Something you cannot really plan for is that you and your team may be confronted with unpleasant surprise late in the development cycle. The design or even the architecture may contain problems related to incomplete understanding of all aspect of used technology. As very good example is not so old DCOM and distributed applications developed using these technology. In development lab conditions, the applications work great, scale well, deployment is easy and running it is no-brainer. In real deployment scenarios where the fast LAN is replaced by VPN tunnels over internet and networking realities such as variable speed, reliability issues, latency, lots of firewalls etc, you have suddenly different picture. I still remember the fun of switching from C++ to Java back at the end of the last century - and few years later switching from Java to C#.
The new business area means that your company and development team enters an applications space in which you have not worked before: e.g. health, genetics, nanotechnology. This may create some communication issues between you and the client who is speaking the language you must first learn. The practical impact is that you do not know the existing solutions in the area, libraries, frameworks, tools available - and very easily you may find yourself reinventing the wheel.
The known/unknown is not a boolean variable, of course, more likely a number in range (let's say) 0 to 3, where 0 is perfectly known territory (like writing seventh Order Tracking system in J2EE, using again Struts and JSP). Number 1 represents some minor unknown areas (for example switching from Struts to Spring or from ASP.NET 1.1 to 2.0). Number two is major change in otherwise known area (like switching from ASP.NET to Winforms or to WPF - but still staying in .NET and C#) and number 3 is something completely new - e.g. Java team trying out Ruby on Rails.
Now evaluate all four quadrant using this scale and add the numbers up to get the risk score. Starting project with risk score in two digits is either gamble or act of desperate measures - and chances of delivering high quality solutions addressing the requirements, on time and within budget are not great. The area between 7 and 9 is challenge zone - you have to expect bumpy ride, but once you do reach the target zone - oh boy, what a feeling. As side effect, when you succeed, usually you make huge progress in your delivery capabilities, team experience, customer trust level or both.
The 4 to 6 is healthy grow. There is very high level of confidence in the project outcome and still enough space to deal with unexpected, get the best out of the team and grow. This is where you want to be most of the time.
The 2-3 score is comfort zone - kind of routine, where you are sort of growing and evolving, but quite slowly. It can make sense under certain situations. I have seen this happening back in dot-com boom when one of our customers kept asking for more and more work on support for their large application that it saturated our delivery capability for quite some period of time. All we could do was hiring and training people as quickly as we could to keep up with the demand. But under normal circumstances, if you find yourself in this zone - wake up and make sure you do not slip into the "binary" zone, where all you to represent the uncertainty factor is single bit. Why ?
Because the levels of 0 and 1 are "death by stagnation". You do not want to be here. No change is bad. Having always same customer, same technology, same business area and stable, unchanging delivery team means that you are not growing: not getting new customers, not discovering new business areas, not keeping up to date with new technologies and not hiring. Definitely not having fun. With that, your skills portfolio will become obsolete and not challenged developers will look for more fun elsewhere.
Author Miro Adamy
License (c) 2006-2019 Miro Adamy