1. Abstractness
A large computer based business information system and its related project is abstract and invisible. The existence of the system can only be verified by painstaking and systematic investigation and the activities on the project must be carefully monitored to have certainty as to what is happening.
It is only possible to evaluate the system one screen at a time, one report at a time. Given the size and complexity of modern systems this is comparable to taking a person, putting a paper bag over their head with two small holes in it and dropping them off in the middle of a strange city to find their way around.
This learning process is extremely difficult and unless one has an aptitude for this sort of thing and works systematically it is very easy to “get lost” and draw wrong conclusions.
A huge amount of what goes wrong with business information systems and their associated projects relates to abstractness.
In the same way the project itself is abstract. A large amount of what is happening is happening in people’s heads. In the first weeks of a new project the consultants are being paid to gather information about the business. While some of this MAY be documented in a useful format on most projects this does NOT happen effectively or is associated with near valueless business process mapping and other exercises, see “Business Process -- Irrelevant, Distracting and Dangerous”
If the consultant leaves and a new consultant joins the team then all that tacit information is lost and the new consultant will have great difficulty working effectively. For this reason tough contracts which enforce consulting team retention are vital.
2. People are PART of the system
It is vital to understand that computers associated with business information systems do NOTHING unless a human being does something. I frequently encounter organizations where management are ready to trash their computer system when the problems are associated with lack of discipline, lack of precision, wrong actions, etc by staff members or consultants.
A simple example, I once did a Pulse Measurement where the system was “losing data” it turned out that the manager concerned was putting an incorrect project number on all of his claims, drawings, etc and a data capture clerk thought she was being very helpful by correcting his errors. But did NOT think to advise him of what she was doing. All the “lost” information was allocated to the project she had redirected it to, exactly as the computer had been instructed to do.
Thus, when one points fingers at a computer based business information system one must be aware that three fingers are pointing back at you!
Frequently the person criticizing is part of the problem so it is a desirable practice to first examine one’s own usage of the system so see if you are part of the problem and this relates to having sufficient understanding AND sufficient discipline.
3. Maturity and Wisdom
There is a mistaken belief that because younger people are generally more adept at learning new technology gimmicks they are better qualified to work in the business information systems industry. This is NOT the case, business information systems are about business, people and other NON-technology issues. Business information systems is about 3% technology and the rest people.
It is vital that your project team includes some mature individuals. On a large project the Project Leader and Strategic Solution Architect should probably both be over the age of 50 and have spent most of their career in business systems.
This wisdom, the ability to accurately determine the REAL issues, understand the business of the client thoroughly and make wise decisions and recommendations is VITAL to a successful outcome.
4. Business knowledge and experience
When a business information systems project commences the business personnel collectively know all there is to know about the business and the consultants know nothing other than general knowledge relating to businesses of that general nature.
A systematic and comprehensive strategic discovery method is a vital first step in any new project.
This entails first and foremost understanding the strategic essence of the business at an executive level and then using this information to prioritize and direct discovery throughout the business.
A key element of discovery is to undertake systematic walkthroughs of every component of the business which includes the physical components, warehouses, factories, transport yards, etc. It is NOT necessary to visit every facility but it IS necessary for the leadership of the external team to walk through a representative sample and, for key team members like senior analysts, solution architects, etc to be part of this. I call this “boots in the mud” discovery – get out there and understand how the business works in order to ensure that you understand how the system must work.
This applies as much to understanding white collar businesses as to understanding mining, construction, manufacturing, etc.
Every business is different, each has its nuances and the choice of the person who conducts the walkthrough is also key. For initial walkthroughs of senior implementer personnel my preference is for the Chief Executive to conduct the walkthroughs and make sure that the consultants see the business through his or her eyes.
It is vital to realize that the consultants will be constantly learning about the business and it will be a long time before they fully understand it and in fact they probably never will. Thus it is vital for consultants to remain open and teachable and questioning what they know.
Note that Business Process orientated investigations are fundamentally flawed in most cases because the consultants dive into producing flow charts, maps, etc on white boards, brown paper or computer screens. By doing this they are so stuck in their tools and methods that they are NOT listening effectively AND they have lost the client personnel who are struggling to understand the method and the diagrams. Note that these things called Business Process Maps are NOT maps, they are very basic diagrams for the most part. Drawings that a cartographer would regard as children’s drawings. They contain so little meaningful information.
In the process of focusing on these drawings the consultant misses a wealth of detail that is resident in the heads of the group AND wastes so much time on the drawing that delegates quickly become bored and frustrated if not thoroughly confused.
See also the article “Business Process -- Irrelevant, Distracting and Dangerous”
It is the nature of human beings that they do NOT want to look stupid, so generally they will keep quiet and play along with the consultant and even agree with the consultant about the interpretation of the diagram, even when it is fundamentally flawed – they have disengaged so the process is all but valueless.
Contrast the above crude diagram with a real 1 in 50,000 geographical map.
This map is associated with a complex and detailed legend and presentation conventions in terms of line thickness, line type, numerous standard symbols, etc all of which combine to present a huge amount of information on a single diagram.
For this reason I assert with confidence that all the business process maps I have ever seen have been a waste of time. They contain insufficient information to understand the business and the manner in which they are generated prevents the facilitators from gaining the required information.
The correct approach is interviews and walkthroughs, take lots of notes, ask lots of questions and then go away and compile a meaningful structured English report that anyone in the business can read and validate that the details of the business have been accurately recorded.
Note that such a report can take two to three hours per contact hour to write IF it is done properly. Alternatively a Critical Issues approach should be used to lift out the headlines. Note that the documentation is LESS important than that the people who will do the work take part in the walkthrough and interview and REMAIN on the project for the duration. See the Procurement Documents for a Request for Proposal directed at ensuring that key staff members remain on team for the duration. This obviously requires that the project is run efficiently and effectively and that team members are managed in a manner that keeps them enrolled and motivated.
If this step is NOT executed effectively the ENTIRE project is placed in jeopardy.
Note that this also assumes that the consultants have the basic grounding to understand WHAT they see, to ask meaningful questions, internalize information and translate that information into meaningful and constructive action downstream on the project.
This means, of necessity, that the lead consultant who conducts the interviews must be senior, experienced and qualified. A business degree coupled with training in analytical, investigative and interviewing techniques should be a minimum requirement.
This is the foundation analysis of the building, you dare NOT cut corners or use under qualified staff or lose the key information or key personnel further down the project.
5. System knowledge and experience
At the start of a project the consultants hopefully know the systems that are to be implemented well.
A key component of the procurement and contracting process must be to ensure that the consultants put forward are knowledgeable about the products being proposed. If the bidder does NOT put forward contractually named individuals who you can interview and establish that they have considerable experience on the product, then choose another implementer or another product or tell them to come back with more experienced personnel. By experienced I mean at least three to five years of hands-on practical experience with verifiably successful outcomes – NOT that easy to find but worth setting as your goal.
You are now faced with exactly the reciprocal challenge to the previous point – you need to introduce client personnel to the software in a systematic and structured manner and ensure that they can correlate the capabilities of the software to the business.
For this reason the walkthroughs of the software should take place AFTER the walkthroughs of the corresponding business components. A software walkthrough is a systematic step by step, screen by screen presentation of the live software with meaningful data, preferably client data. This must take place at a relatively slow pace to give time for delegates to engage with each screen, ask questions and take notes.
During this process it is VITAL that the consultants record ALL concerns, issues, etc that are raised and document them. The first impression is the lasting impression and also frequently the most insightful – things that jump off the screen as being issues or not appropriate will NOT be noticed later.
Recognize that once a client has told a consultant something once they have a reasonable expectation that the consultant will record the point and integrate it into the project documentation, action plan and solution design. Very few consultants recognize this principle and it is a huge problem on most projects – the client says “I told you” and the consultant says, late in the day when trying to raise a variation order, “this is the FIRST time we have heard of this”.
The caliber of consulting staff, their note taking disciplines, etc are cardinal.
Note that the reason consultants should take copious notes at ALL times is that note taking is a means of reinforcement resulting in increased information retention. Listen, frame what you are going to write, write it and as you write read it back – 4 impressions on your brain versus listen while your mind wanders instead of listening attentively – it is virtually impossible to concentrate on what is being said on a sustained basis without taking notes.
6. Solution knowledge
Once the solution design is complete, the software has been built and configured the team, both business and consultants ONLY have solution knowledge. They know, more or less, what they have created. They have NO experience with the solution.
Typically this is the point at which most projects “go-live” with disastrous results because no one really knows how the solution REALLY works.
Solution knowledge includes all the specifications and other design documents and the knowledge of the way the software works at a very basic level.
BEFORE going live the ENTIRE organization must gain solution experience.
7. Solution experience
Solution experience is either gained by doing some minor very artificial training and dumping personnel in the deep end by going live when no one really knows how the solution works OR by training ALL staff up in ALL aspects of the system operation in the Business Simulation Laboratory – see this page on my website for more inforamtion.
It is fundamentally important that the system is comprehensively tested in the laboratory.
Once it is fully tested create enough test data to ensure that all reports, models, alerts, etc are working correctly.
Then develop the training material, preferably interactive Computer Based Learning (CBT) material, and then train ALL personnel who will have anything to do with the system hands-on in the laboratory until you have moved them to the new operating position.
Then, ONCE staff are fully trained in practical simulated operation of the business move them onto the live system and “go live” but NOT before a formal certificate has been issued.
A huge amount of what goes wrong with projects goes wrong because the software configuration is NOT properly tested and / or the personnel are NOT properly trained. A formal and rigorous laboratory is the ONLY way to ensure that problems are prevented.
8. Communication within the project team
Because of the low visibility of the project and the system, communication is vital. Distribute emails widely, have regular meetings and walkthroughs. Apply disciplines to ensure that there is more than sufficient communication.
9. Communication with the broader business community
Keep the business informed. Have a skilled communicator provide assistance. Tell people what you are going to do, what you are doing and what you have done.
Ensure that executives and managers know what is going on at a sufficiently detailed level to ensure that they can manage and guide the project. It is NOT acceptable to work for weeks and then spring sub-optimal outcomes on them.
This may require more communication than they consider necessary but the consequences of inadequate communication can be disastrous.
When an organization builds a new building it is possible to drive past the construction site once a week or once a month or look at a short video and gauge the status of the project. With an IT project that is NOT possible. There must be effective communication and either regular walkthroughs of what has been done and / or regular email communication.
10. Communication with the Executive Sponsor and other executives
One of the major things that goes wrong with business systems projects is when the project team fail to consult in depth with the executive sponsor and, in the case of a large integrated system, the Chief Executive.
Most executives will tell you NOT to talk to them because they do NOT understand technology. This is a misunderstanding that needs to be dealt with robustly, less than 3% of a business information systems project is about technology, the rest is about the business and people. And the people whose opinions matter most are the CEO and the Executive team. It is vital to consult with them and keep them on board as failure to do this WILL result in a solution that is highly sub-optimal.
Note that if the business was engaged in a construction project, for example a new factory or head office building, it would be possible for the CEO to monitor progress by simply driving past the construction site once a week. It would NOT even require that they get out of their motor car.
With a business systems project there is NOTHING to see, just some consultants and staff sitting in workshops and sitting behind computers.
It is therefore vital that there are formal measures to present the work of the project to the CEO and other executives on a regular basis, particularly once the software is configured there should be periodic walkthroughs to demonstrate progress and consult.
A simple way to ensure that the executive sponsor is kept up to date with progress is to set up two dedicated project email addresses. The first, designated as the “For your attention” email address to which all correspondence that requires that they engage and, where necessary respond, is directed. So an address like:
John.Smitt.Attention.XYZ.Project@yourcompany.com
The second email address, designated “For your information” is an address to which all other correspondence is addressed. Typically the Project Leader and Strategic Solution Architect should copy (cc) ALL emails that they issue or reply to the “For your information” email address. An address like:
John.Smitt.Information.XYZ.Project@yourcompany.com
These email addresses should be set up in Outlook or other email client with separate inbox rules so that incoming emails are sorted into folders with names as above “XYZ Project for your attention” and “XYZ for your information”. The option in Outlook to file sent emails in the same folder as the origin email should be set and the executive shown how to ensure that ALL emails relating to that topic are filed in the folder by using “Reply all” – see my video on “Organizing Outlook” for more information.
The executives regular email address should ONLY be used for very important and urgent communication.
The request to the CEO or sponsoring executive is that they engage with everything sent to the “For your attention” address at least once a day. It is only necessary for them to engage with the “For your information” folder once a week or more frequently if they are willing to make the effort. All that is required is that they skim the subject lines so that they have a feel for the level of construction activity and, if a subject line catches their attention dip in and, if they deem it appropriate, comment.
The goal is NOT for them to spend large amounts of time processing emails, it is for them to have a sense of project progress, how the building is progressing.
11. Silence
Silence is one of the most powerful and frequently destructive forms of communication.
Where an executive is kept in the dark because of a lack of communication, it will inevitably happen that when they DO find out what is going on there will be issues where they should have been consulted and this can lead to MAJOR problems, time wastage, rework, claims for variation orders and simply damaged relationships.
Where executives have discussions relating to the project and do NOT make these discussions known to the project team similar toxic situations develop.
Generally the default human position is that IF I am communicating towards you and you do NOT respond I assume that you are in agreement with my message. Accordingly IF you become aware of something that you do NOT agree with the onus is on YOU to communicate.
Major decisions that affect the business or the project team that are NOT communicated effectively can have massively damaging impacts.
12. Relationship management
As I have stated above, IT projects generally and business information system projects in particular are about people and, since they are about people, they are about relationships. Managing those relationships is a KEY responsibility of ALL senior members of the project and business teams.
The book, “How to Win Friends and Influence People” by Dale Carnegie is an excellent guide for IT people who do NOT understand the importance of constructive relationships and relationship management and should be a MUST READ for all consultants. Also desirable that business team members read this.
13. Psychometrics – personality and related factors
The systematic rating and understanding of personality, Psychometrics, is an important element of understanding the psychology and dynamics of project operation.
The diagrams below, based on the Predictive Index approach, demonstrate two very different personality styles.
The upper profile is strongly assertive based on confidence in self (Hi A), highly task orientated (Lo B) has a moderately fast work pace (C) and moderately high attention to detail based on sensitivity to criticism (D). The low B and high A indicate a highly analytical person. This profile, known as a scientific professional, is highly analytical, has excellent problem solving and creative ability. This is the profile of many engineers, systems analysts and similar. In general this profile is NOT good with people and is NOT a good communicator unless they turn communication into a task.
The second profile is a strong marketing and sales profile, strongly assertive based on confidence in self (Hi A), high extroversion (Hi B), moderately fast workpace (C) and average attention to detail (D) resulting in low sensitivity to criticism. This profile is good with people.
These profiles represent close to the extremes of personality styles, generally people with these personality styles will have difficulty understanding each other and will probably NOT get on well.
The first group is good with computers, the second group is extremely bad with computers and avoid them. Thus we get the phenomenon that people who are good with people are bad with computers and people who are good with computers are bad with people.
This is a very fundamental principle that impacts the choice of people to fill roles on project teams from the business side and should play a key role in selecting consultants as well.
The first category are critical to designing high quality solutions and variations of that theme who are less creative and more rule based are vital to executing designs.
People with people skills MAY be of use but frequently muddy the water by their willingness to shoot their mouths off without having all the facts. Typically a person from the first group faced with a person from the second group will retreat into their shell and say very little.
There is much more that can be said about this topic – if you are in an area where you need to know about this I suggest you do some research and consider doing a one day or two day course with one of the mainstream products.
14. Personality Matrix
There is another dimension to the discussion of psychometrics:
The four quadrants represent the four main operating styles of human beings. There are those who are results orientated, they get things done, there are innovators, they are creative, there are people who are relationship oriented, they are marketers and sales people and there are those who work by the book, they are accountants, policemen, controllers.
All four are required to operate an organization but they respond differently to change.
It is a fundamental characteristic of introducing a new system that people are comfortable with the new system and are doing things by the book. So the default cultural position of the organization is in the bottom left quadrant.
The new system and the people who are driving change, both the permanent staff and the consultants are, by definition innovative and creative. They have a vision for a better future.
Thus metaphorically the people in the organization need to be moved psychologically and in terms of workplace skills from the bottom left of the matrix to the top right. Once they get there they again need to stabilize.
There is a catch. It is NOT possible to move people through the center of the matrix, you must move them either around the right along the orange curve of “prove it works”, the results route or around the left along the red curve of “hold my hand”, the relationship route.
Problem is that if you take a person whose natural style is results and try and move them by relationship and hand holding they will rapidly become irritated and you are likely to lose them – you must take a strong and assertive position of systematically proving to them that the new system works and you will have a REAL problem if you try that BEFORE the system works.
And if you take a person whose natural style is relationship and prove it works you will scare them off and lose them. You must take a gentler hand holding approach that is much more facilitative in nature.
This is compounded by the reality that some people have highly developed cognitive ability and can mentally jump from point A to point B in one giant bound, so they do NOT need repetition and reinforcement.
Other people have limited cognitive ability and you need to lead them one small step at a time with considerable reinforcement and repetition.
Then, a further complication, the staff whose personality style IS in the bottom left quadrant, those who work by the book, work by the book. So to get them to change you need to HAVE a book with step by step instructions to get to the new position that MUST work or else they will fall back to their default current state. These people have been employed to work BY THE BOOK so they WILL resist change and will probably be the most difficult to move.
These are your bookkeepers, your management accountants, your production controllers, anybody who is employed to work to rigorous and repetitive standards with NO initiative and imagination. After all we actively discourage “creative accountants”. Yet, when we introduce a new system we NEED them to get creative and to change. So the hand-holding / prove it works journeys must be mapped out for them with particular care.
One of the things that can go wrong with a new system is that these by the book people are seen to be uncooperative and resisting change and so get fired and replaced with more “flexible” people who change more easily but then your controls all get blown away once you get to the new position. You need to RETAIN those staff, they are needed just as much on the new system as on the old.
Note that this dynamic has an impact on designing a new system solution. Those in the bottom left quadrant will want the new system to be just like the old system barring possibly some really obvious and essential changes and will resist change. Putting an inexperienced consultant in a room with such people will result in a definition of the desired future state that will NOT be appropriate when there really IS a need for major improvement. A senior facilitator with the skills to lift out real improvement, working closely with executive and senior management is the way to go.
On the other hand, those in the top right quadrant will invent and innovate and, without effective facilitation will come up with a bucket list of things to do that are NOT necessary and possibly damaging. Since many IT consultants are in this quadrant they frequently drive massive unnecessary change that gets in the way of the business outcome of the project. Projects that go way over budget may well have key players in this quadrant. Again a mature lead consultant who has the ability to moderate demands to that which is really necessary in close consultation with management is a key requirement.
Relationship people who would typically rather talk than do will potentially say things just in order to say things and end up leading inexperienced consultants down convoluted and irrelevant paths leading to seriously wrong design conclusions.
Finally, results orientated people will tend to be very assertive, impatient, not willing to give the time required and very intolerant of mistakes. Generally these people are the main customers for the new system in terms of a valid business outcome. Again mature facilitation is called for.
Thus, to bring about change effectively in any organization one must take account of all the above dynamics.
15. Change facilitation
The above discussion points to mechanisms for bringing about change.
The facilitation of this change requires a particular skills set.
Note that “Change Management” is a misnomer and should be avoided -- one facilitates people to change taking account of the factors mentioned above.
A key element of facilitating change is to ensure that there is proper consultation at the start of the project.
That people’s inputs are taken into account and integrated into a valid and valuable solution design that accurately fits the business.
That once completed the solution is intuitively sound and fits the business – the goal is that when staff sit down in the training environment they can relate what they experience to their work environment with appropriate facilitation where the new solutions deviates significantly from the old system.
A huge amount of this thing called “change management” amounts to the use of blunt instruments to psychologically club client staff into learning to use badly designed and clumsy solutions that are an extremely BAD fit to the real business that they are required to operate in. If the system really is well designed and easy to use AND fits the business well, WITH agreed refinements and optimizations staff will accept it readily and learn to use it quickly.
It is the other sub-standard stuff that requires massive “change management” and experiences poor adoption.
Note that projects that are undertaken with a stated objective of “head count reduction” seldom sustainably deliver reduction in head count because head count reduction is NOT an objective, it is NOT the reason for implementing a new system, it is a natural consequence of a well-designed, well-configured, well-implemented solution that runs smoothly and allows personnel to get more done thereby allowing the business to grow OR the staff complement to shrink by natural attrition.
In cases where there REALLY is a valid head-count reduction outcome this must be managed sensitively with appropriate “golden handshakes” for staff who pull their weight on the project or during the implementation and exit afterwards.
One of the surest ways to give rise to project problems, stalled projects, sabotage and failure is to undertake a new systems project with the goal of bringing about headcount reduction. Fundamentally the benefits and goals of a new system should be MUCH more strategic and far reaching than headcount. See the article on “Attributes of a HIGH VALUE solution”
16. Business integration
An extension of the previous point is that of integrating the solution into the business. This is about getting to a point where the business is running smoothly and the system is an integral part of every part of running the business.
Effective discovery, effective executive led solution design, effective software construction, precision configuration that accurately models the real world are ALL elements of achieving successful integration with the business.
Most importantly an effective business simulation laboratory program is THE key to getting everything working as an integrated and effective whole.
17. Cognitive Span
The mental ability of an individual to quickly grasp, internalize and process information is the “cognitive span”.
A person with an average education can quickly grasp a list with around five points on it. A person with much higher level of education and training in reading and assimilating information may quickly grasp a list of up to about ten points.
Above that number of points all people will battle to rapidly digest information.
This relates to the design of taxonomies and code schemes, the design of data reports, technical reports, presentations, etc.
It is a vital element of crafting high value business information system solutions.
18. Diffusion of Innovations
The diffusion of innovations is a widely known statistical grouping of different categories of acceptance of new ideas.
Inherently this correlates with the number of times a message must be heard before it is accepted.
Diffusion of innovations thinking is directly behind the fact that one sees the same commercial broadcast at the same time nightly on TV for days or weeks. The more the message is broadcast the more people receive it and act on it.
This has huge relevance to business information system projects.
Many IT people are innovators and catch on quickly. They give the client the message once and assume it has been received and understood. Reality is that the message needs to be broadcast repeatedly for the majority of people.
This feeds into the communication program, the training and other elements of the project as a vital element in moving client personnel from where they are to where the business needs them to be.
19. Arrogant ignorance – Dunning-Kruger effect
Another key factor in business information systems is the Dunning-Kruger effect, something that I refer to as “arrogant ignorance”.
Wikipedia reports that “Dunning and Kruger proposed that, for a given skill, incompetent people will:
a. “tend to overestimate their own level of skill;
b. “fail to recognize genuine skill in others;
c. “fail to recognize the extremity of their inadequacy;
d. “recognize and acknowledge their own previous lack of skill, if they are exposed to training for that skill”
This can be summed up by statements such as “when you do not know what you do not know, then you do not know you do not know what you do not know and therefore you make serious mistakes about your level of competence” and by the concept of “unconscious incompetence”.
People who lack knowledge in an area easily greatly over estimate their knowledge and then become proud of the little knowledge that they have. This makes it very difficult to teach them and makes them very difficult to work with.
In the IT field this manifests as consultants with limited knowledge of a system becoming arrogant and unteachable with regard to the huge amount they do NOT know about the system, or the method, or consulting generally, or systems generally. This is compounded by the fact that there are NO entry level requirements with the result that people with the least apparent aptitude are taking into the business systems implementation business and deployed with their limited knowledge and experience as supposed experts.
One of the major problems with IT people is their willingness to say “it cannot be done” when they actually mean “I do NOT know how to do it and I am too lazy to find someone who does know how to do it”.
In the same way these people generally have limited knowledge of business with the result that many become arrogant mavericks who confuse and intimidate client personnel and cause major problems.
On the client side a similar problem occurs with personnel who think they know MUCH more about systems than they really do, just because they have written a simple Microsoft Access application or a macro driven spreadsheet. These people then very assertively drive the business and their colleagues down seriously wrong roads. Coupled with inexperienced and arrogant consultants this is a recipe for a massively messed up project outcome.
There is a huge need for statutory regulation of this industry but that is another discussion.
In the absence of regulation the choice of key project team members, including client executive level advisor, project leader and the like are critical. See the “Procurement Documents” section for an example of a Request for Proposal designed to manage these issues at the procurement stage and into the project.
20. Iterate
A necessary consequence of ALL the above is that human beings simply do NOT “get it” first time. They need repetition and reinforcement.
An extension of this is that it is humanly impossible to get it right first time when specifying a new system, software, configuration, etc.
It is also so that if you do NOT plan for a finite number of iterations and manage to limit yourselves to that number of iterations things drag on and on and you get the phenomenon of tasks that are 90% complete for 90% of the time.
I have found that, in general, if you plan for 3 iterations and manage to three iterations it is generally possible to finalize a specification or other document, finalize a piece of software, finalize a testing program in 3 iterations. But this requires that you plan those iterations in detail and allow sufficient time for each step of each iteration for people to give quality time to the iteration.
Thus:
a. Hold initial workshop – 1 day with lead time of 1 week (2 weeks?)
b. Develop draft specification document – e.g. 1 week – MUST be a realistic time allowance
c. Circulate for review – 1 day
d. Review document – e.g. 1 week – MUST be a realistic time allowance
e. Submit comments – 1 day
f. Workshop to review comments – effectively looping back to (a)
g. Iterate the above steps a third time
h. Approval of document
i. Release of document
Note that the time required for each step of the above process is relatively fixed irrespective of the content and varies only for small, medium and large documents. This allows a full work-breakdown structure based on the above to be developed and copied and pasted throughout the project plan.
This results in a MUCH more realistic plan, much greater plan compliance and much better deliverable quality in less overall time – it is ALL about people after all!
21. The REAL Issues in Business Information Systems
I started speaking about many of the issues discussed in this document as early as around 1992, by 2003 I had presented at dozens of conferences
In 2003 I sat down and undertook a critical issues analysis of all of my findings into the factors causing information technology investment failure and the critical factors for success. This resulted in the two day course “The Critical Factors for Information Technology Investment Success” and the associated book which is available for download off the side-bar on my website.
In 2013 I revisited and revised these factors and they have been addressed in the series of articles “The REAL Issues in Business Information System Success” which is being published periodically at present.
The factors for failure are:
Notice that barring 3% for technology ALL the remaining factors relate to people and what people do. Much relates to what are typically called “soft issues”. The harsh reality is that the “soft issues” are, in fact, harder than concrete.
The Critical Factors for Success are:
Here we see that technology is 2% of what leads to success; the rest is all the people related skills and soft issues again.
It is VITAL to understand that Information Technology is ALL ABOUT PEOPLE!
Because there is NO construction almost all of what takes place on an IT or business information systems project is about people.
People are therefore the FOUNDATION of the solution and the people issues must be constantly addressed.
22. Other Human Foundation
This article has addressed the major factors that seem important at this time. The fact is that ALL that we do relating to business information systems is related to people, the design of reports, the nature of decision making, how to present information graphically, etc, etc.
The subject is huge and generally little understood and widely lacking in terms of the skill set of consultants.