Everyone who's attempted it knows that developing commercical software is hard. And most of us
have tried to use commercial software that just proves the point; it doesn't do
what we want in the way that we expect it to!
As a technologist who has succeeded in this task, I've spent a great deal
of thought in trying to understand and overcome the communications and business
issues and the methodological challenges that face us all.
This presentation outlines my approach to overcoming such stresses and strains.
It shows a structure which will analyse and ultimately resolve them and
help to deliver seriously competitive software
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
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.
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
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
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.
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
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.
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
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.
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.
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.
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
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.
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
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!