From Warfare to Outsourced Software Development

Introduction

Threatened by a good deal of change and uncertainty by nature, software development projects undoubtedly represent one of most risky disciplines in project management, evidenced by the fact that our average rates of success score lower than other more “deterministic” business areas. Let me refer the reader here to the CHAOS annual report, a well reputed study in the field since mid-nineties on a database of thousands of projects of all types and sizes gathered over more than two decades now. In spite of some debates around its methodology, this report shows consistently poor outcomes for software project success.

Great efforts by great industry thinkers have been exerted to enhance our tools, techniques, processes   and methodologies to face this industrial symptom, especially with the increasingly growing challenges since the evolution of the e-anything era to the current flooding streams of the Digital Revolution. We all strive to catch up with these technological  advances to improve our outcomes. However, in the midst of all that jazz, there are still some usually unvoiced practices that we often overlook while  managing software projects. The reason that they are overlooked could be that they  lend themselves  to field experience more than theoretical backgrounds in technology or systems engineering. However, they are practical and pragmatic in a way that can significantly improve our success rates while taking our industrious tasks in building software applications.

What I’ll try to do in this article, is shed light on three of those practices for you to try while leading your  project and see the results for yourself, if you haven’t already, then add to your skill set for the further endeavors if you found them as worthy as I found them.

It follows that our main audience here in this discussion is anyone who’s leading a software project. The discussion, by the way, is methodology-neutral as far as we remain with some agile flavor in what we do. So the reader can follow irrespective of the particular methodology he/she adopts for the development process.

About The Origins

Please don’t shrink back in your seat as you see the title, there are no bullets or shells flying around here! 

However, there has evolved a good deal of resemblance between software delivery and warfare: Both involve some kind of a “battle” in a way. In warfare it’s against an enemy. In software it’s against “failure”, which is by all means, an enemy for any business.

At least, two great works on warfare, The Art of Warby Sun Tzu the ancient Chinese military leader and  strategist and On Warby Carl von Clausewitz the Prussian general and military thinker, have inspired business people a good deal of tactics in managing their business conflicts and relations. 

Now, as we software people are battling for success just the same way the military are battling for victory, we are going to exploit  the resemblance and borrow three major concepts from them to win our battle against failure.

Let’s follow the tricks.

Project Intelligence: A Reconnaissance Mission

Customers are not enemies and projects are not really born as conflicts, but in order to wage your “friendly” attack on your customer, you need to know enough about his territory and capacity. This fore-knowledge is what we call Project Intelligence.

There is a Reconnaissancemission needed here. Never take it as a spying mission, it’s just a matter of ethical deep observation of things as they are naturally exposed to us by the customer. But who are the agents who will do it for you? Just look around you.

Sales and presales are the spearhead in winning the battle of a new contract. Before the win takes place, they spend some good time on the customer’s territory setting up connections, knowing things and people and striving to make it happen: Contracting. They, in this way, can be exposed to quite a good deal of information not only on the pure business grounds, but also on the business politics of the new front, its weaknesses and strengths.

The big loss upon contract awarding, therefore, comes when this constellation of sales and presales intelligence gatherers prematurely disengage from the project, leaving the field to the implementation team alone, without availing their knowledge about the customer’s “territory” with enough depth to them.

I’ve always found it a good sign of collaboration and a very valuable tool for safe project entry that we get an in-depth “handover” from the sales/presales to the PM and the BA.  This sub-process is actually an intelligence mission in the pre-contracting period that sales constellation have to exploit to provide maximum useful information to project management and team, over four main axes:

• The stake holders
• The decision power and dynamics among them
• Business process and requirements. This is the usual part of the story
• The customer’s weaknesses and strengths in knowledge, be that business and/or technological in the implementation domain.

In this way, a project manager can have a foresight about the risks and the impediments that the implementation might meet along the way, hence plan better to mitigate that. As far as the requirements side is considered, and even if the information is still a bit crude,  gathered information would give the analyst a sharper view to plan his/her meetings the best way and start his mission from a more knowledgeable stance, rendering her efforts more effective hopefully in shorter span.

This technique might look more relevant to the “schedule” side of the project rather “Quality and Value” of its yield. In fact, this project intelligence hits both sides, quality and schedule alike. Proper intelligence job avoids “noise“ on the project that we usually encounter by talking to the wrong people or abiding by unauthorized decisions from the customer side. Project noise is a source of ambiguities and rework along the development thus directly hitting the schedule, on the one hand. On the other, the whole perplexed situation affects the team’s morale and focus on the their tasks, hence degrading the quality and the value of their product.

 You can easily say that a proper project intelligence job will certainly reduce that noise on the project, , giving a boost to the timeliness, quality and the value of the delivery. 

Strategic Team Engagement: Moral Mobilizing 

In common outsourcing environments, most of the implementation team (aside from the analyst and the PM) will not see the customer, and their knowledge about the project is restricted to specification sheets, code, UML diagrams, schedules and testing material. What does that do to the teaming process?

If you start a project in this dreary way, well, you will complete it maybe, but at the expense of the motivational side of the story. With time, rest assured that your people will not feel good about what they do, and believe it or not, boredom will gradually seep into their souls driving them mostly to think about new jobs.

In my lectures on leading software teams, I used to dig into my audience experiences by asking them a question “What is the very first thing you do when you get to start a new project?”.  Almost without exception I used to get answers about resources mobilization: capacity planning, budgeting, WBS and task assignments:  Pure “management” sort of things.

The catch here is that there is no “leadership” skill in that answer, only management. And the difference is big! The right answer, back to military analogy, is to motivate the team around the new target and energize them to get their job done with readiness to take up some stress along the way. This the Morale of your Battle. 

How to do that? The answer is simple: Do The Internal Kickoffinside the implementation team as a ceremony that gets everybody aligned with the business side of the new endeavor. Speakers are mainly the PM, the Analyst and could be someone from sales. The objective is to orient the implementation team to overall picture about:

• The business side of the application and the way it serves the customer.
• The market value of the application to the customer.
• The strategic value of the application to the company.
• The anticipated challenges in the application as far as business and technologies used are concerned.

Allow questions, discussions and opinions. Make sure that everyone is engaged. A new project is a new chance to learn and prosper with your team and company, let’s take it and do it.

Of course, you will go into further details on business aspects as tasks are assigned. Just make sure that total business perspective is not lost within chunks of code, stacks of papers of sketches and tables.

In my experience, the approach has a well observed impact on the team behavior, hence performance:

• It adds a new dimension to the pure technical perspective of the developers, helping to lessen the state of boredom that hits them when they work purely technical with their tools which don’t change that often.
• It leaves them with a “feeling of value and respect”. Involving them in such a layer of information is a sure sign that you treat them as “success partners” and not just “task executors”, with all the positive impact on their morale, hence performance and quality.
• It helps the team to gel around one mission. That simply means better collaboration and productivity along the way.

With that simple tactic, you are on the way to make a good take off to your destination with your team and customer; which is success.

The Magic of The First Delivery: The Principle of Surprise

Warfare admits nothing like it for sure victory:  The principle of swiftness of attack, or blitzkrieg  (lightning war) or taking by surprise, all being warfare’s well tested tactics! Here it’s not a war to destroy, but a war to deliver.

Let’s all face it, nothing defines your image in the eyes of a customer more than your first delivery. It’s got to be overwhelmingly useful, impressive, robust, stable and on time. It does not have to be big, but it must fulfill these aforementioned attributes before the size of the functionality included. Actually, the spirit of the agile school lies in the wise selection of the right business value (ROI) to formulate the first delivery, leaving us to care about the quality and robustness of this very special milestone which should never be compromised under any circumstances.

The risk is huge here, if you fail to meet that expectation in your first delivery, be that on schedule or quality grounds, your customer will have an upper hand upon you throughout the project span: A situation that is hard to fix, and that entails a lot of consequences certainly not to the favor of the development team.

On the other hand, if you succeed to make a good show in that first delivery or sprint, rest assured that you have taken the right stance to “lead” the project, including the customer front “tacitly”, to the end of the deal. Just keep it up!

Here comes, by the way, one of the shortcomings of waterfall, or the deterministic school in delivery. Waterfall usually endorses longer phases to build and deliver functionality and get back with that to the customer on phases. Unless you are dealing with a high degree of certainty like the case of building a product of your design to the open market and not to specific customer needs and schedule, then these longer periods of disengagement with the customer represent a voiced call to lose energy, enthusiasm and hence start suffering slackness from all sides. Plus, even if you deliver some deliverable other than “working software”, per se, a design document according to the plan, then just ask yourself who on the customer side will read, critique, review, or comment on it and avail the time (and responsibility) for all of that? We all know the difficulties here, I believe. Seeing a good chunk of customer dreams come true soon enough, is by far different in effect on the customer from spending time to read the most thorough and elegant stack of paper of any kind.

This is what you should do, a Swift Assault! 

But what happens if your customer is not as ready and responding as you need to do your first swift assault? If you ask that question, then I take you are a worthy practitioner coming with field situation to consider! Of course, this is an impediment that we have to think how to surpass. The tricks to surpass it are ready, however I’d say we take that to a separate discussion in a dedicated article hopefully soon.

Finally: Mind The Danger Zone

I won’t leave that swift assault tactic without an emphasis on a conceptual fact in the delivery process, The Danger Zone, as I experienced it and called it. This is actually the period between submitting some  down payment by a customer till  making the first delivery of the contracted product. 

Why is it dangerous?

Software is intangible product by nature, you don’t get it right off the shelf. Even if we talk about packaged solutions, there is still some time lag and human effort to implement and customize to the customer needs. So it’s not like hardware or cars for instance, where you get what you pay for straight away or maybe with some defined lead time but still with tangible functionality the customers knows from the beginning. This means that a paying customer will not feel the value he paid for except when you install the first chunk of functions in his premise, one that meets (or exceeds) his expectations.

When that period of time creeps, the risk on the project goes up exponentially, and you start to meet a case of “hypodynamia” on the customer side which will reflect on the team and will affect the project negatively. A situation which is very hard to recover from, unfortunately.

Conclusion

Building software is a battle for success. From the moment we contract it to that we complete it we are vulnerable to risks coming from change, uncertainty, customer behavior or other team related internal factors. Borrowing some tactics from warfare is a good idea to deal with all that. Be sure that you have done the right “Project Intelligence” exercise to know your customer before you engage. Motivate your people and give them a good view of the value of what they are up to, and its impact on their company as well as their professional careers. Overwhelm your customer with powerful first delivery that leaves him under your tacit control for the rest of the project. Reduce the to the time to deliver the first chunk of functionality, or the danger zone, to a minimum.

Then manage your project.

About the Author

Medhat Sabry is a Software Development Consultant, Speaker and Writer addressing the development community over his own self-constructed web-based initiative called Techstamina, together with other social media and professional networks channels. Staying there in the heart of software delivery process for nearly four decades, Medhat had a sound exposure to the emerging challenges in the development industry that formulated his passion to help developers and companies build their professional stamina to take the ever-growing pressures and challenges in today’s software market.