Despite the methodologies and project management systems produced over the years, it is well known that problems with software development projects are widespread, perennial and still very much with us. People are still getting it wrong and taking too long. A typical response to the problem is 'IT success is not about the technology but about the people.' Others cite user communication or specifications or project control or estimating or programmer productivity and so on. However, our experience and research over the last 30 years leads us to the conclusion that this is a simplistic view and therefore part of the problem. In reality, there is not just one problem but a set of related problems - a problem system.
The solutions we have found that address this problem system are summed up by the phrase 'getting it right first time.' This is met with scepticism by some developers who see this as unrealistic in the environment that they work in. Some others misunderstand. By 'right,' we mean fit for purpose, not spending forever trying to get a system absolutely perfect, but enough time to get it right. By 'first time' we mean avoiding unnecessary changes.
The impetus for creating the course was from our conclusion that poor communication and poor management are perennial causes of the problem. In particular these are poor documentation and carrying out tasks in the wrong order. These cause developers to get the system wrong and take too long to deliver the right system, if at all. So the course focuses on these, although they are not the only causes but are particularly significant and help to eliminate other causes.
RAD without the BAD
Another angle covered is the need to deliver systems as fast as possible, even after eliminating time wasted by unnecessary changes. However just RAD (Rapid Application Development) can be BAD because you just end up with the wrong system faster and even when you get the right one, the lack of proper documentation makes maintenance too slow and expensive. Design of the development process has to consider the entire life-cycle, not just operation. This is particularly important now, with the faster changing business climate and the embracing of ideas like continuous improvement and a learning organisation. However, producing documentation is seen as slowing down the development process. So the problem of speeding up documentation is also addressed.
Seeing something working early on is another need, yet producing documentation traditionally hinders it. This, coupled with the problem of users not understanding the documentation, has led to prototyping where the user sees something working early on. A problem with this, is that it is just a prototype, not the working system. So you have to go round in circles changing it until the user thinks he does understand it meets his needs. However you cannot understand what a system is doing anyway, without documenting it, because it is too complicated to hold it all in your head. We think it is better to produce something early on, which is documented and is right first time. The course shows a way to do this.
The argument that, users cannot understand documentation, we generally do not accept. From our experience, we think this is generally a case of not being able to specify properly. Please note that the course does not go down to the level of showing how to specify in detail. This could be done but would have to be negotiated separately.
You cannot expect people to get these projects right without proper training. As they say, 'experience keeps a dear school but fools will learn in no other.' In addition, even experienced people get it wrong.
The course gradually unravels the problem system and creates solutions in a logical order of development. This is using the general stages-
To help ensure the messages get across, real-life examples are used and learning is interactive. Delegates are asked at several project stages about how they should proceed, given the problem. Also questions can be asked throughout the session, including those trying to relate the ideas to their own situation.
Aimed at anyone involved with software development, it is delivered with minimal technical content, so it will be easily understood by business as well as technical staff.
It is open. In other words, adaptable to any hardware platform or development software. The integration of tasks and deliverables for Project Management, Business Systems Analysis and Programming produces a lean approach. This makes it suitable for large, medium and small applications. The idea is that it can be tailored and optimised to your particular environment.
Aimed at anyone involved in a software development. These could include:-
| Senior Business Management | Users in:- |
| IT Directors/Managers | Finance, Accounting & Auditing |
| Business Analysts, Systems Analysts | Marketing |
| Programmers | Operations |
| Production | |
| Maintenance | |
| Administration | |
| Personnel | |
| Legal | |
| Quality | |
| Health & Safety |
To contact us:-
Email to:vlilley@lilleyinfosys.co.uk
Telephone: +44 (0)20 8573 3911