I respect goals more than most people — having founded or directed a number of innovative projects that’s probably a given. But I also respect a balanced strategy in developing those goals and the forethought to plan for changes.
I decided to take on a project reinventing a product that had over a decade of history behind it. Actually, I was more talked into taking the project by a friend and prior colleague. Over many months we went back and forth on the subject — but eventually I caved and decided to do it. In hindsight, my mistake was obvious. I had let my friend sway me, despite all the cynical bias I usually apply to potential projects.
When I started discussing taking the project on, the terms had already been set in stone. An early adopter client had signed up to foot most of the development cost, the project goals had been established, a target date was set and a contract signed. The project would be delivered for a fixed price. All of this was acceptable to senior management and even seemed reasonable at first. It was understood that the project dates and even the budget might not be “quite right,” but this was a long-term product. A little bit of overrun was to be expected.
As the project director I would be responsible for all technical execution. I would inherit the legacy system’s development team and have the ability to hire a couple of new people if need be. It was an attractive project, but riddled with potential problems. The irony is, I flagged all of these problems before taking the job — and I did it anyway. I was caught up in the persuasive, charismatic message the company President voiced — and two years later I’m reminding myself to keep those cynical biases near at hand.
“Remember that the worst reason to do it is for love.”
It’s important to love your work — in fact, personally I think it’s a requirement. It’s also important that you don’t do it solely for love. I’m a technologist through and through — and that makes my work dangerous. It’s easy to get wrapped up in the moment, to be one of those smart people defending bad ideas. What I need to be is a smart person defending a smart idea — an idea with all the right elements to evolve into a brilliant product, support a viable company, cross to the early majority market and achieve success.
Be objective in your analysis. Long ago someone gave me this advice: “Never invest in your own product.” In other words, if you can’t find other people that are willing to invest, you’d better challenge your assumptions. Maybe the idea isn’t well evolved.
“Look for the chasm.”
If you haven’t read Crossing The Chasm by Geoffrey A. Moore, it’s a worthy read, especially in the technology market. The company’s strategy was wrong. One of the most important aspects of product development is considering how the product will make it to market. That means developing a strategy around early adopters as well as the “early majority,” a group that represents the first half of your market research bell curve. The early majority is your cash cow. Make it into the early majority and you’ve got it made. The problem is getting there.
The root of the issue is crossing the perceived “chasm” from the early adopter to the majority. Early adopters are a rare breed of client. Typically they are actively seeking out new technology. They are often willing to take risks the majority avoids and may even fund development of early projects. Unfortunately, there are few early adopters — most companies can only attract a couple, if even that. And to make matters worse, early adopters make costly demands. Because of the concessions the early adopter makes — greater risks, higher costs, early funding to name a few — they demand greater returns. In a nutshell, they demand a custom project that meets their very specific — and yet often hard to define — requirements.
And there is the rub. If you are building a custom project tailored to the picky needs of your first — and perhaps only — customer, how can you evolve it into a product suitable to the majority? Such a product must be suitable to a wide audience “off the shelf,” robust, complete and easy to adopt. Custom solutions rarely meet these criteria.
To overcome the disparity between a hard to finish custom solution and a generic product of wide utility a company must budget time to “cross the chasm.” The transition from the custom, early adopter client to the early majority is often not an easy one. Products must be retooled, marketing messages revamped, new clients must enter into the pipeline (riding, hopefully, on the good recommendations of your first early adopter clientele). This is a critical time and often one that a company fails to plan for. The chasm was largely dismissed on the assumption that existing clients adopt the new product readily yet no transition plan from early adoption to majority adoption existed.
Even if the project goes without a hitch, there is necessarily a transition from the custom project to the generic product. This time must be budgeted, and funding must be allocated. Glossing over such a transition is a huge oversight — and probably the number one red flag for potential failure.
“Requirements are… required.”
Another concern surfaced very early in reviewing the project. The requirements that had been gathered were far from adequate. The entire work of requirements consisted of a tailored and very detailed request for proposals from the early adopter customer and the idea that the legacy software would serve as a blueprint.
These requirements, as an RFP, where actually very good, consisting of hundreds of pages of needs, desires and parameters from the customer. In many regards it was far more complete than most RFP’s — but it had very little to do with requirements per-se. The RFP was riddled with contradictions, incomplete statements and inaccuracies. The technical detail was simply not there but the business treated it like a finished set of requirements.
For example, round-trip integration between a 20-year-old Adabas court information system was summed up in a few sentences amounting to “there will be bidirectional communication with the court information system.” The effort was dismissed as trivial — yet the company ended up investing well over eight monthsof development time on this oversight alone.
“Don’t ignore unrealistic preconceptions.”
During my early discussions regarding this project a certain lack of grounding in the realities of software product development became clear. It’s important that the entire company is backing up a new project. That means aligning resources and setting goals in such a way that growth into a viable second-stage project is possible.
An early conversation I was a part of should have received more attention from me. “Once we finish the first release, we’ll be able to reduce staffing. Future versions of the product will require little or no additional development,” posited the company President. This attitude surfaced repeatedly, lending pressure to “finish” quality assurance efforts so that we would stop spending money on testing. My initial reaction was simply to dismiss these ideas, thinking that as feature requests, client demands and the realities of business growth became clear expectations would be corrected.
Unfortunately, pressures from the business alone are not enough to change deep-seeded misconceptions. This was a battle I ended up fighting repeatedly. Ultimately, the idea that the development effort should beshrinking rather than growing to accommodate a larger market contributed to the “chasm effect.”
“Avoid compromising on methodology.”
“We already have a contract, we know what we want to do, and really it’s OK if you go over budget. Let’s just get to work.” Sounds great doesn’t but? But it never really works that way. The realities of a business mean that your board of directors is watching the bottom line — unless you happen to work for Xerox Parc, stick to your methodology. Plan your project scope, development an lifecycle, and treat your business as “the customer.” Follow through on every aspect of iteration planning and delivery.
In retrospect I can say that a casual business attitude (such as evidenced by the statement above) is probably the most dangerous situation to get into. Customers will hold your feet to the fire. Investors want to see progress. Paying clients will demand quality and new features. But a seemingly casual business owner isn’t going to stay casual for long. Eventually the project schedule starts to matter. Follow your methodology, emphasize communication and frequent releases to keep the business in the loop, and don’t believe for an instant that it’s OK to take a shortcut. Inevitably, those shortcuts come back to bite you, quite often in the form of misunderstandings around schedules, features or capabilities.
“There is no substitute for a clear contract.”
Don’t buckle under pressure to get things rolling. I’d say at least half, if not more, of my projects have started with pressure to begin work with no contract in place. Clearly, starting work without a contract is in the client’s interest, or at least it seems to be. But what happens when the team is several months down the road and issues start to arise around responsibilities, client involvement, payment schedules and procedures to resolve these matters?
In the worst case you can end up with a poorly drafted contract that fails to lay out clear guidelines for all parties involvement. In this case, the contract was already in place — and unfortunately, none of these details were well incorporated. This can lead to poor client involvement, a very difficult situation with a demanding, early adopter client. Insist on a clear, well structured contract that makes it clear who is responsible for what activities. Incorporate these procedures into your methodology and risk mitigation strategies.
Technically, the project delivered some fantastic technology, but the cost on the team was high. Long hours and very hard work — and as of yet, no clear pay off as the company still struggles to get over the chasm and find a mainstream market. In the long run, I can’t help but think everyone would have been better served had I stuck to my guns. My instincts were to walk away from the project — and in so doing, provide a clear and concise message that the project could not succeed as it was set up.
Entrepreneurs, particularly those with a strong vested interest and long history with a product, can be terribly persuasive. Years of tuning the message and creating an infectiously exciting atmosphere makes them skilled at converting skeptics. Becoming excited about a product is wonderful, but don’t let the euphoria of the moment overshadow the concrete facts.