When it comes to fixing things around the house, I range between Unconscious and Conscious Incompetence depending on the task, (or the prior evening’s indulgences). Recently, while standing in the checkout line of my local Home Depot, (for the second time that day), I looked at the guy behind me and said “What is it about every home project that requires three trips to Home Depot?”
Without skipping a beat he replied – “That’s the Two-P Syndrome”*.
“The Two-P Syndrome? What’s that?”
“Poor-Planning”
I laughed. But then I realized that he was spot on. I could argue that my lack of knowledge makes it impossible to plan. Or, I could use the response I routinely receive from every contractor I’ve ever hired… “I don’t know what it’ll cost until I get into it.”
I thought about IT projects and realized that the same rule applies. The difference is, that with software development projects, you really don’t know what it will cost until you get into it. No amount of up-front planning can accurately estimate the cost of the total project. Why? Because the users defining the requirements don’t know what they want until they can see it, experience it, and test it to see if it even solves the problem.
In this blog series we’re going to explore the problems that contribute to the absurdly high failure rates of IT Development projects and what you can do about it.
*It was actually the “Three-P Syndrome”, but I have cleaned it up for a wider audience [Ed.]
David R. Schulman
Principal, Visualization Practice | Information Concepts
Believing is Seeing
Tell that guy Ed that the 2 P systems explains it perfectly.
Neat, but not gaudy.
Thanks!
Well written. Thanks
ACTUALLY: The military term is the Four-P Syndrome (“P… Poor Prior Planning”) and its working corollary: “P… Poor Prior Planning on your part is no reason for panic on my part!”
Users do know what they want but very seldom do people ask them. I worked on software development teams for First Interstate Services as the User Liaison because I was a user. I had to learn programming and attended FISs development team training sessions. Our first step was to survey current users on what they liked and didn’t like about the system they were using. What reports they got and their usefulness, what data did they want to see on reports. Reports had to be available in standard formats and adhoc options for modifying to customize. Data sets had to be flexible that we could drop and add data sets as the nature of business changed. The training was more to give all programmers rules that made all screens look and act the same as you worked through the program. I had many arguments with programmers about reducing keystrokes because when you multiply that by all the tellers having to enter data, it cost the company much more than them spending a few more minutes programming it properly. Some tried to tell me they couldn’t do it but because I had to learn programming, I knew when they could or couldn’t. When we did beta testing we pulled tellers and staff from the front lines to test. I did adhoc adjustments during testing to get immediate fixes. Anyone making changes had to note date, time, their name and the changes they made. It was the best systems development program I have seen and the product was great. It was so successful they started selling it and added more modules. It was good planning and it made a good system. I loved that company.
Since then I have worked on quite a few systems, installations and implementations. I don’t consider them to be as successful because they did not consider the end user as being very important. It shows and the customer uses the system, but are not very happy with it. And that is sad.