Web 2.0 in the Enterprise

There are many ways to mess up a software project – What I’d like to discuss here is a common misnomer that fix bidding a project somehow mitigates any risk – in fact, fix bidding only increases it. I realize the organizational theory behind this common practice:

“Control costs by putting some of the risk of completing the project into our vendor’s hands”

In the real world, however, the theory does not hold true. There are several things you should consider before asking your vendor to fix bid a software development project:

It’s impossible to accurately estimate software development
First, we need to agree on one thing. There is no software project that winds up exactly like you had planned it. What I mean is that software development is a series of course corrections – if you were able to see all of the risk, and had everything architected and planned out perfectly – than you would be better than 99.999% of all other technology companies in the world. Microsoft, Adobe, nor Apple commit to release dates for this exact reason – they know that software development is predictably unpredictable.

There are only 2 possible outcomes
When you ask a vendor to fix bid a project, there are 2, and only 2 outcomes.

1. You get the vendor to lose money because they did not accurately estimate the project. This may seem fine to you, but the second and third projects you do with a vendor are always more efficient – if your vendor losses money they will not come back (and you will have lost that second project efficiency) It pays in spades to have a vendor understands how to work with you, that knows your business and that can have open communication and collaboration

2. Your vendor is able to do the bare minimum in order to fulfill on the requirements and they make a killing. Recently I interviewed a sales candidate for a large interactive agency. The individual revealed to me that their most profitable projects were those that were fixed bid. He simply took the project team’s estimates, doubled or tripled them, and never told the project team that they had the additional budget. It forced the team to work in a budget that was great for the agency, and horrible for the client.

Given these 2 outcomes, you have now successfully set up an antagonistic relationship. You are constantly questioning your vendor’s motivation, and they are pushing back on every little change because it effects their bottom line. It’s like putting a sword into 2 people’s hands & telling them “winner take all” – and then being surprised when the 2 people don’t get along.











You lose the ability to make course corrections
If you agree that software development requires course corrections, than you must agree that it is critical to frequently review project objectives, estimates, and timelines. It is also critical to validate the software with end users, to make sure the software is meeting their expectations. In a fixed bid situation, your vendor is heads down and not doing the proper check-ins and validations. Even if they do usability testing, they are incented to look the other way.


Bottom of the Barrel
The high risk of taking on fix bid, from a vendor perspective, means that you will likely get only those vendors that are desperate enough to take on that sort of work. Ironically, you have introduced a ton of risk into the project’s success. You might as well take the money to vegas and put it on “Red” … (actually – your odds are better in vegas – according to forester, 70% of all development projects fail because they are not accepted by the end user of the product)











You may ask: “So, how do I manage my budgets?”
First, understand that services companies are not in a “high risk” business. Asking them to share in the risk and not share and not share in the reward is almost alway inappropriate. Yes, you are (hopefully) paying them a great rate for their services and therefore it is completely appropriate for you to expect them to provide quality people and good-faith estimates. But asking them to “put skin in the game” means that you are asking them to do something that is outside of the philosophy of services businesses – Services companies traditionally make lower profit margins; especially when compared to higher-risk / higher-reward product companies. The shareholders in services companies are in that business because they are less risk-adverse than you. Does that mean it is hopeless to mange outsourcing. Actually, outsourcing can be much more cost effective than bringing development in-house. Usually, service providers have people that are more up-to-date on the latest technologies, and have seen many more projects and obstacles then internal project teams.

So – how do you get the most from your vendor while maintaing a good relationship?

1) Treat your vendor as as a partner
A colleague of mine, Rebecca Flavin, explained to me what a great partnership looks like:

A great partnership is where either party would willing trade places with one another

If you think that you “won” because your vendor lost money on a project, think again … Eventually, you will wind up working with only “bottom of the barrel” companies.

2) Demand accurate estimates, but only for short milestones
Trying to accurately estimate a large software development project is next to impossible. One of my favorite quotes in the world was something John Cleese said when he was discussing the value of creativity:

“If you are absolutely hopeless at something, you lack exactly the skills needed to know that you are absolutely hopeless at it — This explains so many things in life”

This translates into software development perfectly. How can you adequately estimate something if it has never been done before, and that you know things will change along the way? The way to mitigate this undeniable truth is to let everyone know the end goal and allow the team to set short milestones and estimates along the way. This gives you, as the project stakeholder, the ability to course correct before its too late. Demand the data you need to allow you to make the right decisions….

3) Be okay with uncertainty
Be okay with the fact that things will not look like you initially planed them (unless you have unlimited cash and time). Agile development is an excellent model for software development. It accounts for the fact that you will never know everything before you start a project – it is execution focused. Do enough planning an product strategy up front to ensure you are headed in the right direction, but don’t get bogged down into detailed requirements documents – they almost never accurately articulate what the software will do when completed. Allow the requirements to build and modify as the project progresses. This DOES NOT mean “give your vendors a bunch of money and let them figure it out along the way” – Agile processes empower you and your vendor to spend the money more wisely, and to have levers to pull when you hit roadblocks or find out that you are missing the mark during user testing.

4) Be okay with some imperfection
Google’s software is in perpetual Beta. They understand that they have an obligation to provide the right mix of utility and usability while trying to push software out in a timely matter. You can easily spin your wheels trying to fix a minor bug for weeks and months and lose sight of the bigger picture. People will allow a certain number of very minor bugs in software as long as they are getting value from it. I’m using Blogo to write this post. It has an annoying bug that pushes my window off screen every time I change my monitor resolution – Despite the bugs, I use the software (and paid for it) because it still offers me more utility than posting directly in wordpress.

That actually leads me to my last point – we often forget that all of technology is geared for one purpose: to improve the lives of human beings. No matter what vendor you choose, or what process you decide to employ, make sure everyone is hyper-focused on that person that will be using what you are building.


For the last year, the industry been hearing a lot about designer developer workflow. Both Adobe and Microsoft are developing tooling that enables designers and developers to integrate more effectively, and iterate on software more rapidly. Let me ask a question that seems obvious: So What? Who does this “rapid iteration” serve?

Look at Adobe’s own diagram for RIA workflow:

Ironically, this diagram does not show true iteration – it only accounts for “design tweaks”. Where’s the business requirements? Where’s the measurement of milestones? And… the most important question, where is the person that the software is intended for?

I’m not completely dense, I realize that Adobe’s diagram is not intended for for use as a project planning roadmap. They aremerelyshowing how CS4 fits into an RIA project – (folks at EffectiveUI often look at our public facing process documentation and complain that it is too simplistic or not entirely accurate – truth is, every project we do is unique in its own way so it is impossible to accurately & concisely diagram any realistic software process)

Where was I …. oh yeah – workflow…

It is easy to get stuck in the tooling and forget about the end result – to value process and the technologies over the final product. There is a shift happening in our industry – I would say we are trending in the right direction. New workflows are forcing designers and developers to collaborate – why is that good? Because it forces humility into the process. In the software creation world, “Big Egos with Big Ideas” rarely produce “Big Wins”.

A Healthy Conflict

Our projects are lead by 2 types of architects. One is technical, of course. But we do not categorize the other architect as a “designer”. Design is just a part of the overall objective. We’ve adopted the term “Experience Architect” – Both architects are held accountable to 2 goals – 1) end user satisfaction and 2) ensuring a business success. While the Technical Architect focuses development architecture and legacy integration, the Experience Architect focuses on the end user and the business and user goals as well as brand consistency and aesthetics.

I have yet to work on a project where no compromise is required. Designers will always need to make compromises because of technical or integration limitations – development will always need to make compromises because of what the end users really need. Where I’ve seen projects fail is when one department is given priority over the other. When design “owns” the initiative, you can wind up with software that looks amazing, but is ripe with performance issues. When development owns it, you can wind up with software that performs, but is not usable. When both teams are equally subservient to the user and business goals – they are forced to work together.

There are some surprising results from this type of structure … interestingly enough, developers have good ideas for usability, and designers can challenge development into new ways of thinking.

What about “me”
It is time to look beyond mere team collaboration; we need to involve the people who the software is intended for. We need to listen and have empathy for those we are creating for. I know – not an original concept… but we must keep saying it until it is heard. New workflow improvements only get us half way there and do not ensure highly usable software…

You’ve gotta read this great post from Ray Valdez – 


He asks the question :

Not to fall completely into cynicism, I grant the possibility that positive outcomes exist: synergistic scenarios in which both the organization and the artifact co-evolve to a better place. My question to you: when and where have you seen this happy circumstance?

We’ve seen this perfect harmony happen with several of our clients – and it usually happens when they are falling behind in the market. When enterprises are starting to lose market-share and are becoming irrelevant to their customers, they start to realize that they can’t “go it alone”. More importantly, they realize they need to change how things are accomplished from the ground up. They look externally not only for help in crafting software, but strategy around how to reshape how they develop and maintain that software internally… Just as companies had to re-think and innovate in the “Web 1.0” world, they become aware that they need to do the same in the new, rich client world.

%d bloggers like this: