System iNetwork

Paul,

Another you may like to add is that often there is never enough time/money/resources to do the job properly at the beginning, but plenty to fix the problems once the project has gone live...

Paul

We don't have to look very far for failed projects, in fact, much to our surprise, we have one right in front of us.

Project : product line Iseries, the Application System par excellence

The project "Executioner": IBM

The customer: the ISV - independed software vendor.

Is still recovering from the shock that his traditional application programs (read green screen) didn't sell anymore for the past 5 years, even not sellable to the Pygmee people in Middle Africa. Then there is the shock of a much to late, weak and fuzzy development roadmap (read gui) from IBM Rochester and last but not least the shock of those few remaining who did follow this roadmap to find out that the response times of these webbish GUI applications is in such a range that only the Pygmee people of Middle Africa would be content with.

The SMB (small and middle sized business) customer:
fed up with an overpriced and ancient looking system (yes, the developer crew is still enthousiast as far they last, you know, retirement on the horizon). One director once asked me how many DVD rewritable drives this system can carry and how many USB and firewire ports it has. I had to explain the technology is still using RS232 serial ports at 19 khz speed.

Ibm could have turned around this machine into a slik GUI application system and they even would have gotten away with an entire new development language if they had this vision in ...... 1998!
SAP beat them to this endeveour 15 years ago.

Now it's all too little too late.

But can IBM abandon this system and retreat, to come out with something fresh in a few years?
Hardly. That would result in, next to the already lost individual customer (the PC market), the loss of the SMB customer, leaving only the large account with his mainframe.
But imagine that, in 5 years, young and dynamic "microsoft" companies coming to the scene building rock solid intel based clusters with redundant storage and cpu power to spare at a fraction of the cost of a mainframe ... that would mean the last battle for IBM. Can't happen can it?

One chief way for a project to fail is that nobody(but a corporate "bean counter" thousands miles away) believes in the success of the project in the first place. The negativity of doing something where there is no apparent logic to it imbues the project from the beginning. No one wants to get blamed for the failure of such a project; therefore, no one take ownership of any problems or provide leadership. Finger pointing, CYA e-mails, meetings where nothing is accomplished, people on extended vacation time, etc. etc

For a project like this to succeed, somebody has to assume leadership and play Tom Hanks on Omaha Beach on D-day in the movie Saving Private Ryan: "This is hell, but we got to get off this beach or we are all going to die!�

One major problem facing the success of an IT project is letting IT drive the project. The data belongs to the user community, which may include IT, therefore, the user community should have a say in the all uses of that data. Project development, reviews, timelines, budgets, etc. should be lead by representatives from the whole user community.

And the user community may even extend to those outside the company, such as the customer who does business with the company/organization owning the data.

The prototype must be created and working before the production system is created!

Every business process must be prototyped front to back

Every application transaction must be prototyped and tested front to back.

Also, each project must have several points at which everyone must take a look at the project as a whole and determine if it is still FEASABLE. You may find things in the discovery phase that make the project INFEASABLE and the project should be stopped before more money is hemoraged.

One more "tip" you may like to add is:

Do not agree on the requirements with the customer, and dont even talk about the policies to accept "last minute" requirements or upgrades.

You can make changes on the fly for sure, it wont make your app unstable, be on time and the customer will surely be happy with whatever comes out.

My favorite is the "auction deadline".

If there are several groups working on a major project, set the deadline for all groups to the nearest date given by any single group.

Personally, I love it when the salesmen drive the project. "I just made a pre-sale. You have to add this little feature"--which happens to be bigger than the rest of the project put together.

Set the go live date before understanding anything about the needs of the project.

ugeerts seems to think the iSeries is a huge failure that SMB customers are fed up with.

We are a SMB who has been running a green-screen package for 13 years. Our vendor has a GUI package as well that runs on Windows. My boss would never consider changing. Our iSeries runs without going down. Period. A good 95% of my time is on Windows server issues. That is the main reason for my failures in developing applications - my time is consumed dealing with Windows problems in a one man shop!

In keeping with Paul's original "tips to make a project fail". 11)Demand that your development staff never talk to the users. 12) Always answer your development staff's questions with "That needs to be answered by the users" (and then never ask the users). 13) NEVER ever let the staff even get a whiff of what real data might look like. {{gasp -- the horror!!}}

Let the boss (client or IT) dictates how the system should be developed and how it should look like. Never consider the requirements from the operational level staff. They just use whatever tools that are given to them, no matter if they fit the job or not.

Tip:

Impose an external team of 'consultants' or 'business analysts' to minimize all communication between users and developers.

Good ways to fail:

Put two people on a one person job. For example, assume coders can't be analysts and allow petulant analysts to leave the room whenever asked to touch a keyboard. Become snobby around programmers who can do it all ... plan, analyze, design, document, code, conduct meetings, interview users and executives, etc. Treat these people as 'not one of you'.

Keep user departments far away from development projects. Assume that it is really an IT project because IT owns the computers.

Hire consultants who provide simple answers to complicated questions. Assume a fine presentation will deliver a complete and perfect application. Pretend likeability equals competence.

Allow programmers to bicker about the best way to code. Threaten to fire those who don't use a coder's eye view of what is best. Assume 'best' means using the most complicated way to get a given result, just because IBM provides the tools and implies it is better that way. Forget about ease of maintainability. Allow the tail to wag the dog.

Think of business problems as a reason to write programs. Assume the only reason other departments exist is just to keep IT busy.

Listen to and obey the most brittle people staffing the IT department. If someone complains about someone else in IT doing something differently then they do it, assume Brittle Person is protecting you from damage. Punish New Idea Person for alienating Brittle Person and remind New Idea Person that it is MOST IMPORTANT to fit in and get along. Fire New Idea Person if Brittle Person keeps complaining.

Punish perople who actually like to work from a plan, even if it is only framework.

Embrace feature creep.

Confuse feature creep with idea refinement as the project progresses. Lock it in early and fix it in the field.

Ignore the problem areas. Apply the 80 - 20 rule in reverse. In other words, assume that the remaining 20% will be as easy to design and write as the first 80%. Put the remaining 20% off until later if problems develop. Or give these remaining parts to a meat market consultant who can be blamed if there are problems later.

Build rather than buy whenever possible. Stick built rather than tool build. Mix as many technologies together as possible.

I could go on, but, believe it or not, this is a trip down memory lane for me. I'm just to depressed to continue.

signed

A former AS/400 application developer

Avoid learning lessons from your experiences. Do not include lessons learned reviews and documentation in your iterative development plans. It is more exciting to get to the end of the project post mortem review to determine how your processes, techniques, and staffing could have been used more effectively. If you have a lessons learned task at the end of each iteration or phase you reduce your chance of having the exciting witch hunt at the end of the project where everyone who did not have a role in the project is hailed as a visionary. Process improvement after all is only for people who don't already know everything that there is to know about robust software development methodologies. These are the same people who somehow perceive that aligning project deliverables with business objectives is somehow better than producing really clever code. After all the business objective really should be focused on adding value to I.T.!

One that's sure to cause disagreement:

Always use the latest technology to develop and implement your project (WDSCi, XML, Java, Eclipse, ) instead of using 'outdated' technology (SEU, RPG, COBOL) - if it's outdated, it shouldn't be used.

Great post Rory! I am an old time Synon/2E, Plex, and RPG developer. The past few years I have been building J2EE Websphere applications for the iSeries. WSAD is a wonderful development tool. All of the OO features of J2EE are great, but ... we are finding as our applications scale, that connection pools and threads become scarce resources using JDBC through a firewall. Of late we have discovered incredible new tools for backend code development. One of the coolest is called RPG! I don't know why IBM has been hiding this new whiz-bang technology from us Websphere guys. What a performance improvement over Java and JDBC. I'll bet if someone took a serious look at it, this RPG thing might catch on as the next generation follow-on to Java on the server. All kidding aside, we have found that the old tools (in our case ILE RPG and AllFusion Plex) are actually supercharging our Websphere applications. Someone asked me this morning how on earth did we ever get off track and start building server side code in Java. We have a Java developer who when he came to us thought RPG was a dead language, and now he is consistently asking for backend code using these 'dead tools'.

Involve senior managements to resolve dependency. While giving sizing try to highlight dependency as much as possible and give sizing with +n days strategy. For example, some piece of work will take +n days after we get an answer from User. To reach a mutually agreed upon sizing of the project ask the respective party to fill up the days to resolve the dependency dependent on them.

---- iSeries developer

Our quest for failure may be easily achievable if we assume that all of the project dependencies will follow the elaborate schedule that we lay out in our project charters. Since we know that all key decisions will be made without delay, all software and hardware will be delivered according to the schedule, and of course all third party performance will meet or exceed expectations - there really is no need to include a risk mitigation strategy in our project charters. No need to plan for risks realized. No real need to estimate going into a project the impact in hours and dollars of risks realized. No real need to develop a mitigation strategy. For that matter there is no need for management at all since project team members all know what to do and how to do it and will strive for absolute cooperation. In fact during the life cycle of our proejct we can be assured that there will be no floods, earthquakes, fire, traffic accidents, water main breaks, or network outages. Its so easy to be successful with a beautiful GANNT chart!

Here are some of the things that I have seen:-
1) Lack of understanding what the user wants. It is like driving in an unknown location without a map.
2) Lack of proper documenting and change management process.
3) Giving outrageous Deadline just to grab a contract.
4) Last minute changes before deployment.
5) Lack of proper Leadership who can manage the whole project.

Here are more ways to fail that, surprisingly, weren't mentioned before:

Pick a random offshore partner that doesn't have local support or project management, don't check their references, don't worry about documentation standards or requirements definition, and don't worry if their project manager isn't experienced.

On the other hand, if you don't want to fail, visit
http://www.FocusITStrategies.com