About the IT Blueprint
How to get IT right the first time
Around 50 - 80% of all major IT projects fail — they are over budget, late, missing requirements or have poor user acceptance. Failures are often blamed on insufficient time or money, bad requirements, bad technology, poor governance, not enough testing or poor project management. The standard ‘solution’ has been to throw more and more time, money and technology at it — all to no avail.
These issues are merely symptoms, not the real problems. Why? IT is the only engineering discipline that operates without a complete and unambiguous Blueprint.
The one fundamental difference between IT and all other engineering projects is that the lack of the Blueprint means that no-one, from the organisation, to the project owner, to the project manager, to the coder or to the tester shares the same vision of the end goal — let alone the end user. In all other engineering disciplines, there is a clear and unambiguous visual representation of the final product that everyone can relate to so they all know what they’ll get at the end of the project.
Business requirements, functional specifications and system architectural documentation are insufficient as it is impossible to fully comprehend and visualise the end goal from so much detail. And what is the end goal? It’s the user interface. To the end user, the application is the user interface — it’s the only they ever see and use, it’s the only thing shown to management to prove the project is done, and it’s the only thing that can be used to determine if ‘this is what I wanted’.
Let’s take a look at the way traditional IT development is handled to see the impact this has on delivering successful projects.
The traditional IT development process
The approach starts with a set of high level business requirements against which a vendor or technology is chosen. As development progresses, the business and the developers are in constant negotiation about what can and can’t be done, based on the capabilities of the technology or the costs and time involved in making changes.
Already the tail is wagging the dog, that is, the technology is dictating to the business. Excessive design iteration occurs from build onwards as management and users finally see the user interface and discover that it’s not what they asked for, or can effectively use. Can you imagine designing the fundamentals of a building while construction is in progress?
This diagram illustrates the way most IT projects are run:
Traditional development is characterised by the following:
- Requirements continuously change, adding time and cost
- Multiple versions, are required to deliver all requirements, taking years to deliver the final product
- The user interface inevitably does not work as people work, requiring constant tweaks and enhancements to get it right
- The business is forced to change its business practices to suit the technology, not the other way around.
Developing IT projects with PTG Global’s IT Blueprint™
The answer is to engage IT, vendors and integration partners only after you have fully defined the IT Blueprint: the business requirements, user requirements, all user interface designs, and the system architecture.
The user interface is tested and confirmed to be usable and that it enforces the business rules and processes. You know the application will work when it’s delivered — all before a line of code is written or a software vendor spoken to.
The resulting IT Blueprint enables executives and users to see and test the user interface in a prototype within weeks or months, not years. You get to see the entire design at the start and buy-in for the project is achieved.
Only afterwards do you pick the technology that will actually deliver what your users, your business and your customers actually want and can use — technology solutions that directly drive individual and business performance.
The IT Blueprint fits into traditional development lifecycles and methodologies. It is the same as engaging an architect before you start building your skyscraper.
The IT Blueprint delivers:
- Communication of functional and non-functional requirements
- A clear line of sight between strategy and application behaviour
- Choice of the right technology solution
- Vendor accountability to the IT Blueprint
- Certainty of outcome
- On budget, on time and usable technology
- The application works properly, the first time
The IT Blueprint works equally well with new and existing applications.
Handling change within the IT Blueprint
The role of the Blueprint is to precisely define the outcome prior to any development starting. However, there are many circumstances in which change is required during development, and the process needs to respond appropriately and provide flexibility.
Change is needed when there are:
- Mistakes (missing or wrong requirements)
- Process changes
- Rule changes
The key to managing change is XPDesign™ and its ability to create a scalable and flexible user interface architecture, separate to the actual user interface design. With XPDesign™:
- Patterns and processes can be modified without affecting the fundamentals and starting from scratch
- Some changes are completely transparent to the design, such as rule changes
- The architecture is stable, while the look and feel and branding can easily change on top
