However, I think these questions are a good starting point for your research before you actually go ahead and outsource an agile project.

1. Why do you want to do the project in an Agile mode?

Here are three possible reasons for wanting to do an outsourced project in agile way. Take your pick:

(A) You are already engaged in outsourcing and have established a good working relationship with the outsourced vendor. You have tried agile way of working internally and it has worked for you. You want to extend it to outsourced projects.

(B) You want to outsource a new project because you do not have internal bandwidth to either work on the requirement or on the development. You expect that outsourcing will help you overcome the bandwidth limitation and agile methodology will help you to evolve the requirements through multiple iterations.

(C) You do all your projects in an agile and to achieve immediate cost saving you plan to outsource some piece of work. So, it is natural for you to choose agile way of executing the project.

If you have chosen (A) then you then you have a good chance of success. The primary criteria for success of agile are trust and good communication and you seem to have both in place.

If you have chosen (C) then you may pull it off but you need to scale your expectation down on the immediate cost saving potential. It takes time, effort & energy to build relationship – initially that is going to be an overhead.

However, if you have chosen (B) then …

As it is, agile is communication intensive. When you bring in outsiders the communication load becomes more. So, if you are not in a position to devote time to understand what you need and create the stories, if you are not in a position to spend time to clarify doubts and answer questions as and when required, if you do not have time to meticulously review the deliverables of every iteration – your project will be doomed.

You should either understand agile well or you should understand outsourcing well before you try agile outsourcing.

2. Do you want to outsource just this project or are you looking for a partner?

This question is relevant only if you do not already have an outsourcing partner.

Agile without trust does not work.

Trust gets established between individuals and not between organizations. There is no substitute for an initial face to face interaction. At the start of the project key people from both sides should together at the same location and work together for a reasonable amount of time. One month would be ideal. If you want to optimize on cost, you should still have at least one week of working together.

Agile without a mechanism for smooth and effective communication does not work.

Setting up effective communication channel, be it dedicated communication link, be it video conferencing facility, be it necessary tooling infrastructure all require investment.

To establish these takes time … and effort … and energy. Doing it for just one project may not give you sufficient return on the investment that you make to get the whole think working.

Therefore, take a long term view and look for a partner who can help you with multiple projects.

3. What type of commercial model you should look at?

There are 3 alternatives – either one or a combination can work for you.

(A) You can have a Time & Material (T&M) contract where you agree on the rate for different people will different levels of experience and expertise and pay the vendor according to how much time they spend on your project. Though this is the simplest mechanism all the risks are with you and the vendor has no incentive to work more efficiently.

(B) The second alternative is to have a Fixed Price contract where you define the scope of the project in sufficient detail and agree to pay a fixed price for it. This runs counter to the basic philosophy of agile where you actively encourage requirements to evolve and change. Therefore, for fixed price to work you need to have a mechanism to compensate the vendor for changed requirement and rework, which you may do in a T&M basis. However, you need to keep in mind that what is a change and what is within scope can become a very controversial topic.

(C) The third commercial model can be based on some objective measure of the amount of work done. People have tried many different methods of sizing like using Story Point or Function Point. Each has its own advantages and disadvantages. The one I like is MK-II Function Point (this and this). It gives a good basis for calculating incremental effort. However, it does not cover effort required for rework, refactoring and impact of technological change.

I do not think there is one best method of structuring a commercial model. However, a good approach is to sign a Master Services Agreement (MSA) which specifies the overall terms and conditions including rate but does not get into specifics of a project. The scope of work can be outlined through a Statement of Work (SOW) which can include high level product backlog.

You may have to try out different model – combination of models – and see which one is best for you. Starting point would be to create a flexible MSA.

4. What payment term should you have?

Since Agile is iterative and there is emphasis on continuously delivery of “potentially shippable product”, you need to pay either at the end of each iteration or you need to pay at the end of a pre-agreed time period like at the end of the month.

If you decide to pay at the end of each iteration then you need to decide if you will enforce a mechanism of accepting the delivery of iteration. You need to decide what you will do if there are bugs or other forms of deficiencies found. You have 3 choices:

(A) You accept the fact that some amount of defects are inevitable and expect that those defects will be fixed in the next iteration and go ahead and make the payment anyway – this is not a very good idea.

(B) You set a threshold of defect and create a separate sprint to close those defects and accept the iteration only after all the defects are closed – this may upset your sprint planning.

(C) You do not your sprint plan but expect the vendor to correct the defects in addition to whatever is expected to completed in the sprint and release the payment only after all the defects are closed – this will put additional load on the team but will force them to deliver better quality product.

There is one more point which you need to keep in mind. One of the benefits of agile is to fail early rather than fail late.

So you need to have a clause in the contract of project termination midway if you realize that you are not going to get the business benefit originally envisaged.

5. Are you sure the vendor understands your definition of “done”?

One of the principles behind agile manifesto says “Working software is the primary measure of progress”.

However, in an enterprise context is that enough? Would the same set of people who have developed the code going to maintain it for years to come? Is there a requirement to follow any organizational coding standard and guidelines? Do you have any architectural standards that are practiced? Is the application usable? What about performance under real life load? Does it have to integrate with other pieces of software?

So, you need to have a clear definition of what is done. Here is an indicative list of points that your definition should take into account:

• How you are going to test the delivery?
• How much documentation is required?
• Is there any architectural or design standard that needs to be followed?
• Do you have a coding standard and code review guideline?
• Do you need to have a Usability testing done?
• What are the integration needs and how will you test it?
• How are you going to measure performance under load?
• Who is responsible for fixing issues while deploying in preproduction and production?

Not having a mutually agreed and a clearly written down definition of “Done” is one of the source of future potential dispute.

Finally…

There is no clear definition of what Agile Methodology means. So you need to thrash out any difference in understanding between you and the vendor. You may find it difficult to adhere to some of the points mentioned in the Agile Manifesto but do keep in mind the 3 important elements which makes Agile agile:

1. Iterative development and regular delivery of working code
2. Self-organizing team and emerging design
3. Direct communication and immediate interaction

Mobile development tools are changing rapidly.

I had started work on comparing cross-platform mobile tools about a month back. I had initially started with a list of 26 tools. Few got added on the way.

However, what is most interesting is that in this short period of time one of the tools (Open Plug) was discontinued. It was a Flash based tool. Since Adobe decided to discontinue Flash for mobile in favor of HTML5 – they really had no choice. Another tool (Pyxis Mobile) has been renamed as (Verivo Software).

Coming back to mobile tool comparison – I had categorized the tools into five categories (here is an overview). They are:

(1)    Mobile Web (JavaScript-CSS library), (here is the detail review)

(2)    Visual Tool (No access to Code),

(3)    Hybrid App (Leverages embedded browser control),

(4)    App Generator (Native application for multiple platforms) and

(5)    Game Builder.

In this post I give an outline of the Visual Tools where you use a visual editor to build the application. Some of these tools do not give you any access to underlying source code.

Here are 5 tools – the ordering is alphabetic.

1. Application Craft

• Home page: Link
• Genesis: It is a cloud-based, desktop and mobile app development environment for building enterprise apps and mobile and tablet content
• Version: Both cloud hosted and in-house
• Licensing: Both free and paid premium – see this
• Download: Not open sourced yet
• Documentation: Video
• Sample application: Link
• Implementation: Crunch Base – Mobile site & YouTube video
• Wikipedia: No
• Additional: Phone Gap + Application Craft
• Article on how to use: Video tutorial, Web services tutorial

2. Dragon RAD

• Home page: Link
• Genesis: Offshoot of Seregon Solutions Inc., a provider of mobile enterprise application platform software
• Version: 4.0
• Licensing: Paid with 30 day free evaluation – see this
• Download: Link
• Documentation: Video tutorial & Webinar
• Sample application: Link
• Implementation: Only one
• Wikipedia: Yes
• Article on how to use: From Zombo

3. July Systems

• Home page: Link
• Genesis: Cloud based solution – tight coupling between development tool and hosting
• Version: 3.5 released on March 2011
• Licensing: Details not available on the site
• Download: Not freely available
• Documentation: Video overview
• Sample application: Link
• Implementation: List of customers
• Wikipedia: Yes
• Article on how to use: No third party article

4. Net Biscuit

• Home page: Link
• Genesis: Cloud based solution – tight coupling between development tool and hosting
• Version: Sitebuilder V2.0 released on September, 2010
• Licensing: Free developer edition – Register
• Download: Not freely available
• Documentation: Overview and Detail Documentation
• Sample application: Hotel.info, eBay.com & mTV
• Implementation:  List of customers – Slide Show and Report
• Wikipedia: No
• Additional: Developer forum
• Article on how to use: DevX.com, Tridionworld.com and  Martin Schreiner

5. Verivo

• Home page: Link
• Genesis: Verivo! Was originally known as Pyxis Mobile.
• Version: Not Clear
• Licensing: Not Clear
• Download: Not Clear
• Documentation: Not Clear
• Sample application: Case studies
• Implementation: List of customers and App Store Links
• Wikipedia: No
• Article on how to use: Stack overflow & Pyxis Mobile from AT&T
• Comment: Because of rebranding all Pyxis mobile links lead to the home page

Have you seen this Wiki?

Here is an interesting wiki – WikiMobidex.org which lists mobile offering from different suppliers. Any supplier can register and add a page for their offering. More than 200 suppliers are listed.

Do let me know if there are any errors and omissions in the details I have provided.

[Update: There are 2 platforms which I have not covered but has been pointed out by readers - (1) iBuildApp & (2) Tiggzi]

Home page: Link

“…some degree of deception present in all three forms (face-to-face, instant messenger, email) of communication, it was increased in both instant messaging and e-mail, with e-mail messages the most likely to contain lies…”

The author goes on to draw the conclusion that “deindividualization” effect leads to lying. When people grow psychologically and physically further from the person they are in communication with, there is a higher likelihood of lying.

No, if you go by what is written in the book “59 Seconds: Think a Little – Change a Lot” by Richard Wiseman. In this book he quotes a study by Jeff Hancock and his colleagues at Cornell University and goes on to say that:

“…people in lied 14% of emails, 21% of texts, 27% of face-to-face and 37% of telephone…”

In this case the author concludes that when somebody has to put things in writing the chances of lying comes down.

[I have not given the details of the study – you can look it up.]

Which is correct?

Both explanations look very logical.

So, what is the truth?

How two academic studies can have such diverse result?

Which one should you believe?

Fooled by Randomness

If you have not read this book “Fooled by Randomness: The Hidden Role of Chance in the Markets and in Life” by Nassim Nicholas Taleb, I suggest that you read it. However, let me warn you that you might be put off by the style of writing.

But for now, you can have a look at these articles which outlines the main thesis of the book.

1. Book Extract – The nature of probability is easily misunderstood, and misinterpretations of statistics abound.
2. Review by Mark Wainwright – Try as we might, we continue to see patterns where none exist, misunderstand the role of randomness, seek explanations for chance phenomena, and believe that we know more about the future than we do. And that is the point of this book.

May be, here lies the explanation of how 2 studies can come to such diverse conclusion.

We live in a complex world

Our world is complex – especially when we deal with human being.

You have to accept the fact that the day of finding simple and elegant explanations for every trend that we observe are over. Any trend that we observe may be just a random event. The cause and effect correlation presented to us may look neat but is likely to be totally erroneous.

Be skeptical of all such studies.

One of the principles behind agile manifesto hints that it is possible:

“…Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely…”

However, the real world is different. We live in a world where we have an obsession with “Growth” … obsession with “Achieving more with less” … obsession with “Goal orientation” … obsession with “Stretch target”. To this you add the fast pace of change in everything around us – you will find that status quo is something which is very difficult to maintain.

Couple of days back I received a mail from Hema and here is an extract from that mail:

“…. I am a big believer in Agile and have been looking for companies that do real agile and have good work life balance. Do they exist or should women just move out of IT industry if they want work life balance if they care a lot about their kids? Are some roles better suited than others?…”

Many of you may echo this same sentiment … may ask the same questions. So, where do we look for an answer?

Assumptions contained in this statement

There are several assumptions inherent in that statement.

• Adoption of true agile will lead to work-life balance
• IT industry suffers more from work life imbalance than many other sectors
• For a specific organization, work-life balance or imbalance will be uniform across
• Work-life imbalance is role specific
• This problem is specific for women

Are all these assumptions true?

Main reasons of work-life imbalance

In my opinion, the single reason which leads to work-life imbalance is when somebody (it may even be you) makes a commitment which cannot be fulfilled without putting in extra effort from your side – and you are not ready to face the consequence of not meeting the commitment.

The reason of why you cannot meet the commitment can be several. The commitment was made…

1. …without an understanding of the complexity involved
2. …in a competitive situation where the options was to either accept the deal with the given conditions or walk out of it
3. …without considering the impact on other commitments already made
4. …assuming a team composition, which for some reason cannot be realized – either people have left or you cannot find suitable people
5. …from the top with the assumption that certain percentage improvement to status quo needs to be done
6. … was derived from some higher level goal and handed down as given

Will adopting agile solve this problem? I really doubt it.

What can you do to avoid such situation?

The problem is not restricted to IT alone – neither is it limited to certain roles. Even if you are a school teacher you might find that you have been handed out with responsibilities which go much beyond teaching.

Agile practice, by itself, is unlikely to help you achieve work-life balance. Given today’s business environment it may even make it worse.

Here are few suggestions which may work. Though, I should warn you that our world has become complex enough and competitive enough to ensure that you need to run fast to stay at the same place.

1. Learn to say “NO”. There is lot of stuff written on how to say no – just do Google it. Many people believe that Steve Jobs succeeded because he could say no – Steve Jobs: Get Rid of the Crappy Stuff.
2. Learn to “Slow Down”. Did you know there is something called “Slow Movement”? There is even a Wikipedia page on slow movement.
3. If you are still confused about what you want to do read this book – What Should I Do With My Life? Remember one gentleman called William Henry “Bill” Gates – he just walked out from the most successful company at that time which he had built from scratch.

Finally…

Here is an interesting report from McKinsey titled Changing companies’ minds about women or see this link. So, there is some hope for women. However, things are not changing very fast, so …

There are consequence to “saying no”, “slowing down” and “changing your career”.

Be clear that you understand those.

If you listen to Eric Schmidt, it is off course Facebook. Off course anybody from Google will consider Facebook in the list because Larry Page is turning Google upside down to compete with Facebook.

However, if you go by what Jeff Bezos say then it has to be Microsoft. According to him “…they’ve done a lot of innovative things, some of which get overshadowed by their big existing businesses…”

So, who will it be – IBM, Facebook or Microsoft?

Consider the following facts and possibilities

• Since 2009, IBM share has outperformed Microsoft (see this).
• In the same period Google and Microsoft stocks have performed about the same (see this).
• Facebook IPO, when it comes, is expected to round up anywhere between 50 billion to 100 billion US$ (see this).
• Facebook’s IPO would be 6X bigger than Google’s (see this).
• IBM has replaced expensive workers in North America with low-cost laborers abroad, which has helped keep margins and profits growing (see this).
• By the end of 2012, Google+ may become the second most popular social media site (see this).
• Google surpasses Facebook to become the most visited site of 2011 (see this).
• Microsoft has a habit of coming from way behind and winning the war (see this).
• IBM has bet big on analytics including cloud analytics & “Big Data”. The icing on the cake is when Watson won Jeopardy! (see this).
• Microsoft has created the MetroUI for Windows 8, which has the potential of becoming a game changer like Kinect (see this). Or, will it be a flop like Vista.
• The fate of Nokia and possibly Intel depends on the success of the next generation Windows OS (see this).
• An x86 tablet with Windows 8 running all the legacy applications … anyone (see this)?

Ultimately it boils down to these 3 questions…

1. How successful will Windows 8 be, especially for the Tablet?
2. Will Facebook come up with an IPO and if it does how successful will it be?
3. Is “Big Data” the next big thing in cloud or is it a solution in search of a problem?

If you have been following then you would probably have guessed that I feel that the first question is going to be a game changer.

If Windows 8 succeeds then it would be as disruptive as iPad or Android – it would have blurred the distinction between PC and Tablet.

On the other hand if it fails then posterity may consider this event as the starting point of the end of PC era.

It happens to me quite frequently.

For example, recently, I read an article on “10 Ways to Sell an Idea” by Dennis McCafferty which I found to be quiet contrary to another article I had read few years back. I wanted to locate the article and it took me a long time to do it. In fact, it took me more time to locate the article than to write the post comparing the contrasting view – How to Pursue You Innovative Idea – 2 Contradictory Perspectives.

Now that Google has started leveraging your and your friend’s activities for searching – it may be an interesting idea leverage that to find stuff that you have liked in the past.

After I had added by blog to my Google+ profile, I have found it easier to search any of my past post by directly searching in Google rather than going to my blog and looking for it. Since the search result is personalized, the post that I am looking for invariably shows up in the search.

For example, to look for my post 6 Game Changing Technology Events Of 2011 – And 2 Non-Events I had to just type “6 events and 2” and bang the link shows up as the third item.

Obviously, when you do a similar search, you will not find the link.

Here is an interesting study from IBM – Tip for Getting More Organized: Don’t

So, that opens an interesting possibility.

Why not just keep liking and sharing all the post that you might find interesting? You may be able to find it easily in some distant future.

To ensure that complexity does not turn into chaos it is inevitable that the pure agile way of working may have to be sacrificed – is it possible without violating agile manifesto? It is also inevitable that the agile practices will need to integrate into other practices of the enterprise.

To be able to scale agile we need to understand:

• What the dimensions to this complexity?
• How to split the problem and the team?
• How to introduce processes and tools?
• How to manage collaboration among distributed team members?
• How to plan and manage workflow?

Dimensions of scaling and the need to integrate with other enterprise processes

Scaling Agile: An Executive Guide – Scott Ambler

To scale agile to an enterprise level, eight dimensions of complexity needs to be handled.

1. Team size – from less than ten to hundreds
2. Geographical distribution – from collocated to globally distributed
3. Regulatory compliance – need for mandatory compliance
4. Domain complexity – straightforward to complex and emerging
5. Organizational distribution – from all in-house to multiple external parties
6. Technical complexity – from homogeneous to heterogeneous including legacy
7. Organizational complexity – from flexible to rigid
8. Enterprise discipline – from no external constrain to need to adhere to enterprise standards

Different options of splitting the teams

Scaling agile teams – by features or by component? – David Draper

There are four options to split a large team into smaller sub-teams

1. Component orientation: (Pro) Typically this is how developers align themselves. (Con) Need to split user-centric feature – focus shifts away from business value.
2. Discipline: (Pro) This is how enterprises are already organized. (Con) Risk longer lead times with a “throw over the wall” attitude.
3. Location: (Pro) Collocated teams tend to be more effective. (Con) Need to match feature set with specific team.
4. Feature: (Pro) Aligns well with goal of delivering value. (Con) Integration issues may arise.

In practice a mix-and-match approach may be best where the split is done primarily based of feature and location.

Harmonizing the tool and process dimension with agile practices

Scaling Agile for Project Teams – Alan Bustamante & Rahul Sawhney

There is a need to harmonize three dimensions of people, process and tool. Here are some of the recommendations on how to achieve it.

1. People issues are best tackled through structure, empathy, communication, and people-oriented policies.
2. Addressing process challenges for scaling requires organizations to understand their process focus and validate that it is aligned with the organization’s vision, mission, and values.
3. Focus on tools that support and facilitate the team and sub-team’s processes by eliminating or minimizing non-value added work.
4. Configuring tools around a flawed process will still yield a flawed process. Fix the people and process issues first.

Making distributed teams effective through communities of practice

Scaling Agile to work with Distributed Teams – Mike Cohn

Total team size increases complexity. Distribution increases complexity. It becomes impossible for all team members to know each other let alone trust each other. One way to build the bridge is to set up communities of practice.

• A group of likeminded or like skilled individuals which is self-organizing, organic and can span projects / location
• All communities need not be officially sanctioned – they can completely informal to highly institutionalized
• Creating proper environment for the communities is important

Managing the product backlog at multiple levels

Scaling Agile Processes: Five Levels of Planning – Hubert Smits

Agile planning activities for large-scale development efforts should rely on five levels:

1. Product Visioning
2. Product Roadmap
3. Release Planning
4. Iteration Planning
5. Daily Planning

Product Vision is more like a desire of what the product will deliver once it is finished and would not talk about specific features. On the other hand Product Roadmap would talk about high level product backlog from which backlog for lower levels will be derived. It will communicate when releases are needed, what would be sufficient functionality and what business value would be delivered.

Like the two previous levels Release Planning is also for all the teams. Releases are defined by fixed date, theme, and planned feature set to which all teams must commit to. Typically, the product release would be once a quarter and the iteration cycle would be 2 to 4 weeks.

Managing workflow between multiple teams using Kanban

Large-Scale Agile – James Shore

Use Kanban for workflow not within a team but between teams.

1. Treat each agile team as a work cell
2. Use Kanban to manage cross-team workflow
3. Create a Product Portfolio team which is collocated, cross-functional, intact team consisting of product managers, business experts, UX designers, architects etc.
4. Partition the teams in such a way as to minimize the dependencies
5. Monitor the system using lean techniques which is Visual control, Throughput and Value-stream mapping
6. Sacrifice reuse in favor of throughput
7. Keep communication flowing with Scrums of Scrums

Finally…

Since, to scale agile, we may have to deviate from the spirit of the original manifesto, the question is how much can we deviate and still call the resultant methodology agile? And, when does it become an iterative development methodology?

Incidentally, iterative development seems to be as successful as agile development. Have a look at this survey outcome.

Apart from the fact that Agile has been consistently been more successful compared to traditional approach, these survey result show two more interesting result – one of them is very surprising.

1) The gap between “Iterative + Agile” and “Traditional + Ad-hoc” has been increasing

It is not clear why there is a dip in the success rate of all types of project in 2010. But, leaving that aside, the gap has been consistently been increasing (2008=7%, 2010=13% and 2011=18%).

So, does it mean that people have really mastered the art of how to manage Agile and Iterative projects?

Or, does it been, people who are good at project management have abandoned Traditional approach and migrated to Agile or Iterative approach?

2) Iterative approach has consistently performed better than Agile

Though the difference is not very significant, all the 3 survey has indicated that iterative is slightly more successful compared to agile.

Does it imply that all the stuff in Agile Manifesto about “People over Process”, “Co-located Team”, “Face to Face communication”, “Cross functional team” etc. has very little to contribute to project success? When you scale Agile, you may need to violate some of them anyway.

Agile@Scale ≠ Agile@Manifesto

Word of Caution from Scott Ambler

He is quick to point out the known challenges with any survey.

• You will only get responses from people willing to be surveyed
• You risk getting responses from people with strong feelings about the topic
• Very often questions capture opinions, not facts
• The biases of the communities will be reflected in the results

This means (1) your survey sample may not represent the real world, and (2) your result may be based on opinion and not fact.

BUT, the question that we need to ask ourselves is…

…Has the time come for us to examine, which of the agile practices have a +ve correlation with project success and which are only rituals with no impact on the project success?

]]> http://setandbma.wordpress.com/2012/01/03/agile-projects-more-successful/feed/ 2 Udayan Agile Project Success http://setandbma.wordpress.com/2012/01/02/agile-contracting/ http://setandbma.wordpress.com/2012/01/02/agile-contracting/#comments Mon, 02 Jan 2012 11:33:44 +0000 Udayan Banerjee http://setandbma.wordpress.com/?p=1598 Read more]]> Irrespective of what the Agile Manifesto says (“Customer Collaboration over Contract Negotiation”) we do require signed contract for ANY medium to large software outsourcing engagements – and that includes agile projects.

Why? Because when there is a commercial arrangement between 2 parties for delivery of any service where a significant amount of financial transaction is involved, there needs to be a clear agreement on:

1. What is the service that is going to be delivered and what will be the charges for those services?
2. What happens when things go wrong?
3. Do’s and Don’ts of how the interaction will happen

So, any contract for agile project outsourcing also needs to answer these points. But, how will an agile contract be different from a traditional software outsourcing contract?

This Post is based on…

Major part of what follows comes from the whitepaper Agile Contract Premier by Tom Arbogast, Craig Larman, and Bas Vodde. I recommend that you read it.

I have also used some ideas from the following posts:

• Agile contracts – Alistair Cockburn
• Contracting Agile Projects – Jens Coldewey (Cutter Consortium)
• Agile Contracts – Allan Kelly (InfoQ)

Let us see what these practitioners have recommended.

Is it possible to have Fixed-Price, Fixed-Scope (FPFS) agile contract?

Yes, it is possible but it should be avoided.

• Requirement specification that is signed off is almost never what is actually needed
• In an effort to deliver something within the constraints of price and scope, suppliers will often degrade the quality of their work – reduced code quality, do less testing etc.
• Price include large risk contingency – this premium is usually hidden in the effort estimate

As a result, the customer may not get what they want and supplier may lose out because of changing requirement.

How can the supplier make such project work?

• Use people with experience of the domain and the technology to estimate the effort
• Clearly lay out the acceptance definition or the definition of “done”
• Ensure that new requirements only displace existing requirements if they are of equal effort
• Decide how additional requirement will be charged

FPFS contracts are common where there is low level of trust between both parties. This may be a starting point in the engagement and it the project is successful more flexible contracts can follow.

What are the options available for Variable-Price, Variable-Scope contracts?

Such contract normally starts with a Master Services Agreement (MSA) which is more like a rate card. The rate may be for people deployed, cost of each iteration, function point or story point delivered etc.

Since we are talking about variable-scope, there will not be any detailed definition of scope. However, there may be an overall cap to the total price of the contract.

Some form of an order may be released for executing the next iteration or next couple of iterations which will have a clearer definition of scope or backlog.

To cover the risk the contract may be terminated after completion of any iteration – agreed termination charges may have to be paid.

Can you have a completely transparent payment model?

Yes, if you follow Toyota. It is called the target cost contract. They follow this five step process:

1. In collaboration between customer and supplier, identify, analyze, and estimate all possible project requirements.
2. In collaboration, estimate the cost of change or scope increase during the project.
3. From these two elements, establish the target cost.
4. Calculate target profit, based on target cost (for example, 15% of target cost).
5. Share all details and results with customer.

The idea is to have a trusting relationship where pain and gain can be shared by having a mechanism to adjust the actual cost based on the changing scope.

How do you protect against things going bad?

This is clearly the domain of the contract lawyers. They are supposed to ensure that contracts are drafted in such a way that suitable clauses are in place favoring their clients.

It is essential that non-lawyers involved in negotiating the contract understand the lawyers point of view.

However, one of the key premises of agile methodology is that the project risk is reduced through iterations and early delivery. So, it is strongly recommended that lawyers working on such contracts study and understand how agile method reduces risk.

This can help in significantly simplifying the contract.

Successful projects happen not because of the contract but because of many other things including collaboration, transparency, and trust. There are many natural roadblocks in the path of a successful project delivery – the contract should take care not to add any more roadblocks.

After all under normal circumstances everyone’s number one priority is to deliver a successful project. (There are situations where some people may want the project to fail.)

Steve Jobs, the genius is no longer with Apple.

Would you like to take a bet that within next three years, Apple will not be able to come up with another game changing innovation like iPad, iPhone, iPod, Mac or Apple PC?

2. Google goes social

Paul Allen says Google+ growth is accelerating and passes 62 million users, adding 625,000 new users per day and will probably have 400 million users by end of 2012. Whether this will threaten Facebook or not is less important than how this is going to affect search result.

Google knows much more about us than we can imagine – sometime you may feel that it can even read your mind – it is scary.

3. Microsoft chooses Metro UI for Windows 8

This bold decision is either a make or break for Microsoft – well not necessarily for Microsoft but for their OS business. If people reject it then Microsoft can say goodbye to mobile and tablet OS. But if it gets accepted then surely there is a chance that they will go on to be a strong player in both phone and tablet OS market.

Mobile and tablet UI needs innovation and Metro UI may just be that.

4. HTML5 has won the mobile war

What is going to stop HTML5, especially in the mobile? All leading players have adopted it – Apple, Microsoft, Google and now even Adobe. Have you seen the HTML5 version of Angry Bird?

Yes, HTML5 has won – would it have happened if Steve Jobs had not refused to allow Flash in iPhone?

5. Watson- Breakthrough in AI influences Google

How big a deal is IBM Watson winning Jeopardy!? It is just another milestone like Deep Blue beating Kasparov in chess which did not have any game changing effect? What is more interesting is how this has affected Google. Just after Watson won, Google has started replying to your search query with an explicit answer and it is continuously improving.

Are we moving towards an era where there will be an all knowing machine which will answer all questions?

6. Motion sensing technology comes of age

Which is the “Fastest-Selling Consumer Electronics Device”? No it is not the iPhone or the iPad. It is, according to Guinness Book of World Record, Kinect for the Xbox 360 which sold an average of 133,333 units per day, for a total of 8 million units in its first 60 days on sale from 4 November 2010 to 3 January 2011. Microsoft seems to have made significant breakthrough in motion sensing technology.

Is this going to be one of the key building blocks of required for a household robot?

A. No Facebook IPO

This is really an event that did not happen. Why did it not happen? Is it due to the launch of Google+ which spoiled the party, or the informal valuation of Facebook already too high?

Or is this a sign that social networks has less influence on buying decision than what people would like to believe?

B. Nothing on Cloud Computing

I cannot think of even one event in cloud computing which is worth a mention. That by itself is worth a mention.

Is cloud computing losing its value proposition?

Other not so significant events

Significant product launches

• Android 4.0, Ice Cream Sandwich
• Windows Phone 7.5, Mango
• iPhone 4S
• Galaxy S2
• iPad 2
• Kindle Fire
• Google+

Merger, Acquisition and Strategic Partnership

• Microsoft purchased Skype – $8.5 Billion
• Google buys Motorola Mobility – $12.5 Billion
• Nokia and Microsoft join hands

Patent war

• Oracle suing Google over Android
• Apple-Samsung patent war

Related Articles

• Top 10 Technology Events Of 2011!
• Infographic: Top Tech Trends of 2011
• Top 15 Technology events in 2011
• Top Tech Moments of 2011
• Technology 2011 in Review: Highlights and Lowlights
• Technology Highlights Of The Year (2011)