Debunking the myths of IT development
The Performance Technologies Group
Category: development | Author: Craig Errey | Date: 01/03/2006
Introduction
The forty plus year history of IT application development, characterised largely by a high cost of success and a low degree of predictability of outcome, has produced a number of myths. These myths, perpetuated by technologists and management alike, are used explain away the high cost / low success outcomes. They have generally been accepted as ‘that’s just the way things are’.
They have also formed the basis of what is now considered to be the ‘right’ way to do things. The purpose of this article is to debunk those myths and offer an alternate way of thinking. If the just mentioned myths aren’t challenged, with new ways of managing IT established, IT is destined to continue to repeat its troubles. George Santayana once said ‘Those who cannot learn from history are doomed to repeat it’.
In a previous article, we discussed a significantly revised software development lifecycle (SDLC). Approached with a new mindset, this new SDLC has the ability to reduce cost and time to market of critical business applications.
I’ve assembled 10 myths of IT development that must stop:
1. Iteration is a good thing
2. It’s OK that requirements change throughout the lifecycle
3. Off the shelf solutions will work out of the box
4. Offshore outsourcing will solve the cost of IT problem
5. IT provides a competitive advantage
6. Don’t worry, we can put it into the next version
7. The lowest priced bid is best
8. It is wise to pick your technology partner first, especially for enterprise applications
9. You can’t always know the end goal, so you should build a bit — use bit
10. The user interface is always the last thing you do, and it’s just graphics anyway
There are many more, but I’ve found these are the most damaging to IT, business and the end users.
Myth 1: Iteration is a good thing
It’s commonly accepted that software never works properly the first time, and that iteration and multiple versions is the only way to get it right.Rarely does the underlying logic that needs iteration, it’s the user interface. The main issue is the endless rounds of iteration that take place during the user interface design step when management and users are shown the application and IT needs to go back and ‘fix it’ so people can use it.
This happens because the user interface is designed much too late in the development lifecycle and people can’t visualise the application from text specification, or early prototypes that keep changing. It’s only when people can see a prototype that they can find missing requirements or problems with the user interface.
What should happen is that the user interface is designed at the same time as the business and use requirements are gathered, creating a visual representation. This can be tested with users to confirm that the design is usable and meets requirements. With the right design methodology, the prototype does not need to keep changing.
Myth 2: It’s OK that requirements change throughout the lifecycle
’The business changes to quickly’, ‘We can’t tell how things will be a year down the track when the application goes live’, therefore, ‘requirements have to be in a state of flux’.
If the requirements continually change throughout, and even post the development lifecycle, how can these changing goal posts do anything but add time and cost to the project?
The ‘requirements’ must be absolutely precise, covering the business rules, policies and procedures, the user requirements, all user interface designs and the required system architecture to deliver the requirements. It’s easy to say ‘you can’t know everything in advance’ — and, sure, that can often be true. But if we focus at the constants and foundations of business, rather than the exceptions, then we can build a stable architecture. It’s a bit like a building — while you may not know precisely what it will be used for, that doesn’t stop you from designing and constructing one that will do the job, almost no matter the purpose.
Myth 3: Off the shelf solutions will work out of the box
Management buys off the shelf software on the premise that most of it is done, ready for use, and they will only need a small amount of customisation.Unfortunately, off the shelf solutions generally have a predefined way of doing things (i.e. specific sequences in which work processes occur) and it’s highly unlikely that this will perfectly suit your business. After all, this is the developer’s or vendor’s view of how business should operate.
Don’t get me wrong, chances are very good that it will algorithmically work fine, but the vendors are good at technology, not the user interface. It’s highly likely that when your end users get to use the solution, they’ll say it’s too hard and doubles the time it used to take to get things done.
Before you select a vendor, you need to ask: ‘what do they really know about running a business?’ ‘How do I know that they way they want me to do things is best practice?’ ‘Will my staff be able to use it quickly and effectively to comply with my business policies and procedures?’
Myth 4: Offshore outsourcing will solve the cost of IT problem
With the financial benefits of cheaper labour in other countries, businesses think that the increasing cost and time of IT projects can be mitigated by offshore development. While this certainly makes for much cheaper development, if requirements are wrong, vague or missing critical components, all you’re doing is building stuff that doesn’t work faster and cheaper than before.
If you think this is the right way to combat rising IT costs as development spirals out of control in ongoing change requests, then you’re mistaken. If you’re not delivering on the business goals and objectives, and providing a user friendly solution, a large opportunity cost is unavoidable.Therefore, before you engage offshore developers, get your requirements precise, and your user interfaces complete. Then the developers have a clear representation of what they need to build and you won’t end up with more of ‘that’s not what we wanted’.
Myth 5: IT provides a competitive advantage
That IT provides a competitive edge is losing its status as a myth. Certainly in the heady days of the dotcom boom, it was all about IT. But then, as it is now, IT is a commodity and you can get it anywhere, anytime, very cheaply. And if you can get it so easily, so can your competitors. Fancy IT systems are no longer the envy of your mates — but IT that works the first time is.
IT is a necessity to run most businesses and what customers want is an interface to your business that is quick and easy. As customers become more and more sophisticated and use a variety of suppliers, they develop expectations, as well as tolerance levels, for IT.
Just take a look at Staples in the US — their tagline is ‘that was easy’. Their aim is to differentiate from other online and offline retailers by providing the best possible customer experience. Given that their competitors can get the same IT as they have, Staples needs to differentiate in they use IT to create a compelling customer experience — now that is a competitive advantage.
Myth 6: Don’t worry, we can put it into the next version
As a by product of Myth 1, management and users generally expect the application not to have everything in the first release — usually due to time and budget overruns and poor requirements. IT and management think that they can always get it into the next version. Imagine if when you by your next car, Manufacturer A said ‘this car is the best on the road you can pick one up right now — but the on board computer and doors are still being built and will be ready next year’. But just down the road you notice Manufacturer B advertising their new car — complete with on-board computer and doors. I know where you’d be shopping.
As with the IT as a competitive advantage myth, customers (and staff) are developing a baseline set of expectations about how IT works and the features and benefits they need. If key requirements are missing, they’ll simply use something else, or the old system — it immediately undermines your strategy. People will not put up with using one application for half the functionality and then switching to another for the remainder. Sure, you can make them do it, but consider the productivity hit you’ll inevitably experience.
There is no competitive advantage in technology, per se, but there is advantage in well customised and designed technology.
Myth 7: The lowest priced bid is best
Business is naturally concerned by the fact that IT projects are often over budget and late. Therefore, in an effort to mitigate that risk, they often pick the lowest priced bid - to ensure there are sufficient funds left to fix the inevitable problems, as they arise.
On the other hand, the vendors are quite comfortable to come in at rock bottom prices, knowing they’ll make it up in change requests because of myths 1, 2, 9 and 10. They remove key steps like requirements, user interface design and testing because, after all, they just waste time and money, don’t they?
Rather, the entire vendor engagement model must be rethought. Specify the requirements up front, including the business and user requirements and the user interface designs in totality and use them to engage a vendor that can actually build what your business, staff and customers actually need — that is, a solution that suits how you want to do business.
Myth 8: It is wise to select your technology partner first, especially for enterprise applications
When the business decides it needs an ERP, CRM or other enterprise application, they invariably think about choosing the vendor first. This seems logical — after all, it is all about the technology, isn’t it? Or is it?
No it isn’t. Performance in business is much more than just shoving in a new piece of technology and thinking that everyone will get on board. There are many factors that contribute to business performance, such as staff skill and motivation, the organisational culture, rewards and recognition programs, and organisation systems, processes and technology.
Instead, consider engaging a change management partner to help you define best practice in your business processes and using this to form the basis if the requirements. When the business processes are clearly spelled out then you can pick a vendor who can deliver what you and your customers need. But don’t forget that if the user interface makes it too hard to use, your staff will go back to their old ways. Check out Myth 1 and 10 for more on interface design.
Myth 9: You can’t always know the end goal, so you should build a bit — use a bit
On large IT projects, with lengthy timeframes, there is typically the view that you can’t fully define everything because it is next to impossible to predict what the business will be like at the end of the project.
There are a couple of issues here. First, why does the project have to take so long? Second, why become confounded by superficial differences in the business between now and the future? Rather there should be a recognition that the fundamentals really don’t change very much over time. For example, the accounts department you have now is not likely to change in the near future, nor is the process to capture and track staff development needs. The detail of what you capture may change, but the fundamental steps in the process do not.
It is virtually impossible to design and develop something if you don’t know what the end goal looks like. Further, without the right approach to user interface design, you end up with applications that evolve over time and have little or no internal consistency.
There are things that are persistent over time, general rules, practices and approaches that provide a foundation for business activity. Get these right, in a well structured design, and you can make changes without having to start again.
Myth 10: The user interface is always the last thing you do, and it’s just graphics anyway
For several reasons this is probably the most damaging myth of all. Firstly, to the user, the user interface is the application. If they do not accept the system and instead implement their own workarounds such as spreadsheets and access databases, a key management strategy may be undermined. Secondly, in the case of a package application, the user interface is the primary means for the business to achieve customisation. Thirdly, evolving from a ‘balanced scorecard’ view of the business, it is management’s means of reflecting and driving their key strategies. In spite of this, the UI is commonly given little airplay.
For the just stated reasons, a poorly designed user interface, generally arising from poor requirements, coupled with no design skills, is the primary cause of IT failure. If people can’t use your application, it doesn’t matter how clever you were with your super-efficient, elegant algorithms or how big your server is.
This myth is perpetuated because user interface design is seen as a black art, hard, wishy-washy or even unnecessary. Contemporary approaches to UI design such as (iterative) user centered design are by nature time consuming, adding delays to the project, and are therefore left to last. During IT’s rush to get the application done and meet that all important deadline, their approach is typically that they can do the interface ‘properly’, later, after delivery.
For these reasons, it is critical to start with the complete design — just like a building blueprint — it makes the whole development process simpler and faster. As is the case for a building developer, an application blueprint fully defines and controls the IT application build process and everyone knows exactly what is required.
Conclusion
You mightn’t agree with some or all of these, or you might think I’m being harsh on IT and management. Take the time to review the way your projects are going and see if you can do something different to get it right the first time.
