Iain Downs - Commercial Software Consultants

The Problem

Often, technology seems to be an isolated department. No-one else understands what they say and no-one else feels they quite get through.

But in truth there are necessary linkages between technology, three internal departments and three external areas. If these links are weak or too tense, then the result is imbalance, inflexibility and poor performance

The Internal Relationships

Internally, the Technology team has important relationships with three departments, Marketing, Sales and the Board.

I've actually worked as a sales manager and a board member as well as interacting extensvely with other departments - especially marketing, so I've seen the situation from both sides in many cases.

Marketing - Features and Functionality

Marketing's job is to understand the customer, the competition and the market. But there's a tension here. Marketing do this well, but are not equipped to deeply understand the technologies that are currently being used or under development, so their research tends to reflect the present and the past - not what may be.

Technology can help here - they do know where things are going. But they don't clearly understand what the customer wants or what the competition is doing - which is where Marketing is so vital!

The relationship between Marketing and Technology defines the Features and Functionality of a product. If this link is weak, then the features won't meet the needs of the customer at best and could catalyse missed targets / increased costs at worst.

Communication is the key here. I speak both languages!

Sales - Product Delivery

A forceful salesman comes back from a meeting and tells a developer, 'I can sell HUNDREDS if you make this change'! The bemused developer does this (possibly without telling anyone) and the next version has this unexpected new feature. Did this change really sell hundreds? Did it add more value than it caused confusion? Likely no one will ever know.

The relationship between Sales and Technology sits in Product Delivery. If this link is weak - if the sales force don't understand the product or find it awkward to sell then there will be confusion and poor revenue.

Of course, it's normal and positive to see tensions between the demands of the sales force and development priorities - but this tension needs to be managed to keep it productive.

Make sure you have some way of tracking changes. It may be simply a weekly meeting with notes or a full change control system.

The Board - Budgets and Timescales

The Board has a responsibility for setting strategy, monitoring progress and risk management as well as ensuring that process is transparent. But the technologists and the Board don't seem to talk the same language.

The Board just KNOWS the development is going to cost more than estimated and take longer. And the technology team just KNOW they have been pressed to pare down estimates below the realistic and anyway there will be at least one major change of direction in the project which will mean their plans all get thrown out!

The relationship between the Board and Technology focuses on Budgets and Timescales. Getting this right is critical to profitability and trust.

Make sure the board engages with technology decisions. They must understand the risks of choices made. This is a dynamic process - risk changes as we discover new options and aspects of technology.

External Factors

But the Technology department also has to maintain external relationships.  It's a fast changing world and good technologists have to be aware of best practice, technology advances and, of course, the customers and competition.

Sometimes these can be the hardest areas to keep balanced - because the pressures from inside the company are much more immediate. Nonetheless, these are critical areas.

Best Practice - Risk Management

The relationship between Technology and Best Practice is about Risk Management.

Risk Management is not just about identifying potential problems and alternatives in the development process; it’s also about understanding the value of architectural or product features so that risk can be balanced against benefits. Furthermore, technologically novel aspects of a project should be identified and trialled early in the development process or even before it starts!

Best practice is not something that is mature for our profession. To start with the tools and implementation processes are changing faster than the theorists can keep up with! A process which supports Risk Management is key but the nature of this must depend on the company, the culture, the technology and the kind of software which is being developed.

Processes which work have good communications with all stakeholders and are flexible; what we start wanting is rarely want we finally understand we need!

Technology Advances - Technology Learning

You may think that techies are always up to date in the latest technology, and that is certainly their goal. But in fact, there is simply too much changing to keep up with more than a fraction. This may be particular true of technologies related to process or perhaps technologies that competitors use but your company does not!

The relationship between Technology and Technology Advances defines the Technology Learning of the organisation. It's important that you know what your people already know and that the right new knowledge is discovered and distributed to the right people in your team.

Make sure you have developers tasked with being expert in your key technologies. Have them build presence and relationships in Forums.

Customers & Competitors - Product Priority

What are your development priorities? Without understanding customer need and competitive offerings, the development plan may start with features which are less business critical and the important ones may fall off the end if development slips.

The relationship between Technology and the Customers and Competition helps define the Product Priorities. You should develop the features which provide the most value first so that you have a sensible choice between slipping delivery or reducing features if time gets tight.

Furthermore, it is imperative for the development team to try and see the product from the customer's point of view. The more direct the relationship, the easier this is.

Make sure your development team have played with competitors products and tried to take them apart; show them parts you like and parts you hate.

Strategic Challenges

As well as these 6 tactical interactions with the Technology Department, there are another 6 relationships formed by our model. Each of these relationships interacts with Technology in a strategic way - let's see how.

Threats and Opportunities

The interaction between Technology Advances and Customers and Competition defines Threats and Opportunities. Traditionally, Threats and Opportunities are the province of Marketing, but without support from the Technology department how can they understand the implications of changes in underlying technology and simply what can be done?

The triangle formed by this combination should define the product Architecture or Road Map.

Ultimately the product road map is the synthesis of the technologist's vision of how the underlying technologies will develop and a collective view of how the customer needs will change over time. Although it is nearly inevitable that a technology road map will change over time, it is important to have a shared goal for all to aim for.

Do think ahead past the next release. The balance between getting a product out the door quickly and making it easy to extend is a tricky one, but important.

Business Case

The Business Case for commercial software product's is often generated by the relationship between the Marketing Department and the Customers and Competition. They identify needs in the market and deficiencies in their and other products.

But the business case depends fundamentally on what is possible and how much it will cost. Technology must provide this together with the vision of can be done - and furthermore this will work best as a strongly interactive and iterative process.

The triangle defined by this combination represents the Product with its features and benefits and development priorities.

Be realistic about the value of features - and the risks associated with them. Implement the most profitable features first and the nice-to-haves later.

The Sales Proposition

Marketing define the sales proposition - and sometimes Sales blow it out of all recognition! Ultimately it is the Technology department which knows what the system does and can help balance this equation.

Moreover, this triangle defines the Saleability of the product. Something given far too little thought.

If developer time and Marketing and Sales thought can reduce the time and effort to sell and support the product, this can be paid back by decreased cost of sales and support over the entire product lifecycle - and so a bigger bottom line.

Can your products sell themselves? Or at least reduce the time your sales force spend in sales meetings through demos, example data. organisation of features and so on.

Revenue Delivery

Ultimately the Board look to Sales to Deliver Revenue, but this is reliant on quality and timeliness of the Product built by the Technology team.

This triangle is about the Bottom Line. Is the product or company profitable? Have we sold enough? Did it cost too much to build for the revenue? Are ongoing support and selling costs too high? All of this flows from ensuring that the product is right.

Check what the customer really needs and compare it to the development risks. Don't build high risk bits no-one wants.

Process mapping

The Board are rightly concerned that development is done the best way that it can be; that 'Best Practice' is followed.

But best practice is an uncertain thing in such a young and swiftly changing profession as software development. There simply is no commonly accepted best practice and the attempts to introduce best practice from other fields (such as engineering) have not succeeded. So it is up to the Technology team to work out what best practice is for their company and competitive sector, technology, culture and product and ensure that this is clear to the board.

The triangle around this area is about reporting. Does the Board know what is planned and what is happening in the process? Can they make sensible decisions when options are presented and if the unexpected happens?

Make sure the board are kept up to speed - especially on issues. Being late is not exactly unheard of in software. But finding out about problems TOO late to make choices is bad.

Tools

Like much other software, software development tools can prove unwieldy and hard to learn. But without basic tools like source control and bug tracking, development is chaotic.

And many of these tools can amply repay their costs and learning curve with hugely improved productivity. Things like build management, UI and database designers and refactoring tools can take a great deal of tedium off the developer leaving them to focus on the hard and creative parts of development.

The triangle formed between Best Practice and Technology represents the Methodology of the development process. Choosing or designing an appropriate methodology produces huge dividends in the smoothness and transparency of development.

Development must have a methodology. But it need not be a burden. Where possible design or select your methodology to be flexible.

Summary

So you can see that the development process is complex. What's worse is that these relationships are rarely well understood and can easily get out of alignment.

Creating great commercial software requires a flexible and holistic approach with all the linkages working smoothly; Far too often each area operates in it's own Silo with not enough communication.

And it's easy to see why. Commercial software development is a young discipline and still changing rapidly; the best practices and interactions with older disciplines are still being worked out.

The question is, what can be done to make the process help you compete better in today's rapidly changing and competitive environment?

How I can help

It's easy enough to see if you have specific areas or linkages that are unbalanced or too rigid. Simply take the diagnostics - a 2 minute questionnaire which lets you analyse your organisation and check out the results.

This is a good indicator of the stresses and strains in your commercial software development.

Talk to me - I've spent a great deal of time distilling my 25 years experiences into a model and a methodology which can help others learn from my experience.

Let's make your software help your profits!