Software outsourcing strategy – Decision Making. Introduction

Here is the initial article from the planned set of articles aimed to help with your first steps of software development outsourcing.

The article has aim to help IT projects sponsors and managers in making the decision about software outsourcing strategy of the company by answering the following questions:

• Correct estimation of expenses and comparison with domestic development
• Estimation of risks and their influence on final price
• Selection of the software provider
• Reorganization of the domestic work

Part 1. Take your mark.

It’s not recommended (especially at the very beginning) to outsource the planning of your project! Project development plan has extremely high level of influence onto the final success, never lose the keys – keep track of all details of the project plan.

Before proceeding with any outsourcing activity it would be good to prepare own implementation plan. That is please forget anything about external bright outsourcing propositions from companies that will during 1 month and cost of 499 dollars will deliver “Google killer” search engine. So even the most crucial idea is not enough: do all possible actions like brainstorming, works planning and efforts estimation with your trusted partners. Prepare all planning based on available or virtual resources. Make sure that this should not be very precise final implementation plan, consider it as start approximation that will be used to compare and evaluate external propositions.

Now you have not only the bright idea of a new mega project but also the initial estimation of planned steps, resources and efforts.

The main idea behind outsourcing is optimization of software development costs, so to find idea about the real expenses one should consider some alternatives and do own calculation for various development processes. At first stage it’s proposed to use planned man-hours for estimation of expenses rather than money. One should not be confused with fact that planned man-hours for outsourcing always higher that for the domestic development (with equal resources qualification), that is due to the extra communication, controlling and coordination efforts.

So one could take any own project and try fill in figures for domestic development, each effort estimation should be accompanied by role (who performs specified task).

The proposed roles are:

• Project sponsor, [PS]
• Project manager (domestic), [PMd]
• System architect (domestic), [SAd]
• Developer (domestic), [Dd]
• Tester (domestic), [Td]
• Project manager (remote), [PMr]
• System architect (remote), [SAr]
• Developer (remote), [Dr]
• Tester (remote), [Tr]

In most cases the listed above is enough for the first estimation.

With the following part I’ll show example of filling the table and consequent estimation steps.

To be continued… "Part 2. To outsource or not to outsource."

Pnn Soft Company Presentation

Check out this SlideShare Presentation:

Pnn Soft Company Presentation

View more presentations from gueste54471.

Why software project fails (in real life, not in theory) ?

LinkedIn brings the question entered as title here... Good question :)
Particular example appears bit long...
Some standard reasons like incomplete requirements, multiple changerequests, planning release date w/o WBS was present, but not detailed in the article... more emphasis to the startegical managment mistakes.


So, "Why software project fails?", let’s go the real life story:

Place:
Europe, Earth
Actors:
Producer Company
Major customer
3 remote teams

Act 1 “Once upon a time”

The Producer Company developed the big analytical system for the nationwide client and do permanent support of the client. With time go the system starts looking bit obsolete and it was decided to create the new version. Company had growing ambitions and new project was announced to reach the International level. Long time of gathering and combining information ends up with software requirements specification document.
Here comes the first disagreement between expectations of Major customer (having experience with old version) and potential customers. The Major customer had much strong influence on to the project and compromise point appeared very close to his position. Unfortunately the agreed compromise was not clearly stated with requirements and comes as bifurcation point, so it was international version as designed and customers’ version “as expected’.

Act 2 “Start the ball rolling”

3 dedicated teams are hired to develop separate project parts together with Producer’s Company team. It was planned to start with software design description, but in reality start with reverse engendering of old system as almost only source of technical information.
Here comes the second disagreement: the roles and responsibilities of teams and players are not clearly stated. And as a result all 5 scene players do job following own understanding of the tasks. … and all this in a dark room with personal lights. With “personal lights” I mean that each team has own internal business process with planning, issue tracking, source control, etc.
Lack of centralized system do “overheating” of Producer team which in this situation was responsible for manual dispatching of planning, issue tracking, sources among teams.

Act 3 “Long recovering”

Finally the fault situation becomes clear for all and after some traditional "witch-hunt" period it was taking initial steps to improve the overall workflow. First it takes only formal common planning-reporting tools… good try, but not enough. What’s next? Overall Roles and Responsibilities + escalation procedure. Escalation not working… Internal auditor… No result… External auditor (have good trust level from project manager/sponsor). Perfect shoot! Issue tracking. Yes! Common document and sources repository? … postponed

Act 4 “Cool wind”

Process tuning is nice, but customer expected the product for the specified deadline. And it become obvious that system couldn’t be completed in specified terms. Hard negotiations bring to surface the next problem: tough discussions lead to tensions between Customer and Producer; and final acceptance of almost all requests of Customer makes additional pressure for time/budget of process. From two evils here was selected… both (relations come to bad, planning is not corrected).
Extra consequence of the conflict was reorganization of management in Producer Company. More, it was done not in single shoot, but prolonged for some period ("witch-hunt 2"). Really not a good for the team climate, but the main processes are set and running, so development is continued and productivity strongly increased.

Act 5 “The End”

New management of Producer Company finally stabilized the internal process: working compromise between correct formal process and minimal required organization. And completely switched to management of Customer expectations… to late. It was some positive effect: works are continued, but anyway customer expected more and earlier. Final turn of hard negotiations with customer was finished with cancellation of contract. So practically ready for use product (beta version) appeared irrelevant for both Major customer and international customers as well.

The dry essence mistakes, that leads to the project fault:

• lack of Customer expectations management strategyHaving a “hard” customer one should plan and do steps for controlling and managing customer expectation. The worth case is to escalate conflict to reject some change requests and finally accept all “as is”


• lack of distributed teams management experience when running big projects with international teams. Experience of running domestic “in office” projects not guaranties effectiveness of known methods for managing offshore teams. Local projects are more stable and have stronger trend to self organization. So in reality starting local project as “ad-hoc” one could expect the process level somewhere around CMMI level 2 – 3 after rather short period. With distributed projects this “self organization” practically impossible and one should take care in advance on planning and implementing the process for managing distributed offshore teams


• special attention in management process to teams and roles management. Having a clear picture of roles and responsibilities for each player extended with effective escalation rules could save a lot of time, especially at initial stages. In opposite case one could face with multiple “input missing deadlocks” or duplicated work