I spent four months in the Discovery Phase of a major project.
It had some of the most complex business rules I'd ever run into. The idea was to build a data platform to move the company's data from third party vendors into a custom data warehouse. That's where it started. As you'd expect, the scope blossomed like a mushroom cloud in 1950s Yucca Flats, Utah.
I concentrated on the original concept since others were dealing with the side projects. I created a matrix of coupon-mailer-product and took a week to write some pseudo code to demonstrate the machine logic required (it wouldn't fit into a single Use Case- the best I could do is add my 15 pages of 8 point pseudo code to the 53 pages of the rules and walk the developer through it). The SMEs approved it. It was like pulling teeth. You'd get smiles and words of assent, but some of the folks I was dealing with were playing company politics and pretty much ignored the Use Cases for their multi-million dollar data application/framework.
About a week before I was scheduled to leave (real old school - using Iterative Methods). I chanced to talk to a director about something else in the Smoker's Lounge. Nice guy, very knowledgeable. He politely asked me how we were coming and I outlined what I'd done to date. "You mean you're not creating coupons when xxxxxx occurs? We've been doing that by hand for years."
Turns out there were twice as many business rules and decision trees as I had.
The rules and logic were in someone's desk drawer. He thought we had a copy. Even though I'd asked him for the rules at least four times. "Yeah, you mean I forgot to mail it to you?"
I left the project three days later. Blamed for the failure.
The poor development team would have to do it from the original material which had been amended about four or five gazillion times since it was written in 1856.
Here's what I should have done and have done ever since in Waterfall and Iterative Methodologies:
Best of all, we create software without games or gotchas.
It had some of the most complex business rules I'd ever run into. The idea was to build a data platform to move the company's data from third party vendors into a custom data warehouse. That's where it started. As you'd expect, the scope blossomed like a mushroom cloud in 1950s Yucca Flats, Utah.
I concentrated on the original concept since others were dealing with the side projects. I created a matrix of coupon-mailer-product and took a week to write some pseudo code to demonstrate the machine logic required (it wouldn't fit into a single Use Case- the best I could do is add my 15 pages of 8 point pseudo code to the 53 pages of the rules and walk the developer through it). The SMEs approved it. It was like pulling teeth. You'd get smiles and words of assent, but some of the folks I was dealing with were playing company politics and pretty much ignored the Use Cases for their multi-million dollar data application/framework.
About a week before I was scheduled to leave (real old school - using Iterative Methods). I chanced to talk to a director about something else in the Smoker's Lounge. Nice guy, very knowledgeable. He politely asked me how we were coming and I outlined what I'd done to date. "You mean you're not creating coupons when xxxxxx occurs? We've been doing that by hand for years."
Turns out there were twice as many business rules and decision trees as I had.
The rules and logic were in someone's desk drawer. He thought we had a copy. Even though I'd asked him for the rules at least four times. "Yeah, you mean I forgot to mail it to you?"
I left the project three days later. Blamed for the failure.
The poor development team would have to do it from the original material which had been amended about four or five gazillion times since it was written in 1856.
Here's what I should have done and have done ever since in Waterfall and Iterative Methodologies:
- Identify each and every stakeholder and find the possible politics that can impact the project. Make sure it's in the Risk Management Plan with mitigation strategies. No seriously. Doing that would have saved the first phase of the project.
- Identify every document passed to me (I was swimming in that Project from Hell, but I didn't catalog each piece of documentation). I could have identified gaps with a simple spreadsheet.
- Draw more pictures, tables, graphs and diagrams. I used to think a multi-million dollar project was probably worth reading the Use Cases. Silly me. Pictures. Color. Arrows. Boxes. The third or fourth rule of technical communication: make sure there's at least one graphic in each publication and if the document is in color, it's more important than one in black and white. You think I'm kidding, doncha? I'm not. Its true- ask any tech writer.
- Always, always look for evidence of hidden requirements. And then look again.
- Keep asking polite questions and reflecting what the SME says back to him or her until I'm certain I understand what s/he is saying.
Best of all, we create software without games or gotchas.
Powered by ScribeFire.
Posts
Exactly right Scot. On a project I worked on that used waterfall, two different sets of testing requirements magically ´appeared´ late in the project for independent modules of the final product (4 and 5 months down the line of a 6 month project).
ReplyDeleteIf there had been a product backlog where each module received genuine focus as the sprints progressed, we´d have found and nailed these gaps during that iteration. As it was, we had code developed 2 months previously which suddenly had to be revisited, retested and refactored, throwing the project plan into more disarray than it was already in.
It just makes more sense to deal with development of complex applications using an iterative approach. The human brain can´t cope with project plans which could be used as murals or paper the wall of an average house - they´re too big.
I work in a science research environment with many very intelligent men and women. Nonetheless, eliciting requirements for software projects, both large and small, is very difficult. I have found that scientists like to describe the solution they need. I then need to deduce, from the proposed solution, the requirements. After a few iterations we are usually able to converge on the real requirements, which often go beyond those met by the originally-proposed solution.
ReplyDeleteI have always wondered if this situation is peculiar to the scientific research environment, of if it is common in the business world as well.
Hi Scot,
ReplyDeleteThank you for being transparent and sharing the pain - we all too often only share what goes right...when we know there's a bunch of stuff in every project that goes south. Hearing what you would have done differently helps me to remember the basics.
Agile sometimes seems so simple - too simple for folks that like to do it fancy. If we just keep it simple - then the team can engage and help gather requirements. It's not just you.
You might like the WEBINAR I'm hosting next week on 11/3...interviewing the author of "Becoming Agile - in an imperfect world". You might like it or share it with folks trying to use Agile more. Goto http://ow.ly/xeQv
Keep it up.
DONNA REED
MY BLOG: http://www.DonnaAReed.com
EMAIL: donna@DonnaAReed.com
Hi Kenny-
ReplyDeleteI think we need to advance from Iterative (mistakenly called RUP/UML since those tools were developed around the same time. Yes, it sounds like Iterative would have helped, but if the project was done in an Agile environment, the team would not only expect changes, it *manages* the changes throughout the lifecycle...knowing that when you put the code into the customer's hands, you're going to get changes.
I have yet to have the customer know exactly what s/he wanted at the beginning of a project. You have the people who have a vision of what they'd like and you have those without a single clue- they only know they need *something*. Until they can play with it and we (the customer and I) can plot the As-Is work flow, there can't be a To-Be framework, can there?
Hi Mark-
ReplyDeleteNo, that's a fine description of virtually every stakeholder with which I've ever worked.
When a stakeholder starts telling me what architecture the solution requires, how the work flow will go or exact wireframe descriptions, I have a decision to make. Do I simply ignore them and ask the questions to which I need answers (politely) or do I need a way to shunt their enthusiasm in some way (foist him/her on the Project Manager, create a blog or wiki page for them to 'capture'their thoughts and vision.
The first thing that needs to be done is to define the scope,boundaries and very very high level functional requirements. I tell the client we can either start in the weeds or look down from 60,000 feet- either way, I'll get what we need, but its easier for me if we stay high. If they can, I can keep them high through my questions.
I then abstract the As-Is picture, confirm my charts, scope and boundaries. I can then design the To-Be picture that will meet the objectives (actually, me, the business and the development team), which wil then point the way to dependencies and a potential order of development which the business can adjust according to its needs.
When we're done with that, then we can talk about the cool stuff they were talking about at the beginning.
The driver is the business and what it needs, not what it wants.
Hi Donna-
ReplyDeleteThanks- sorry I didn't get a chance to participate in the Webinar, it would have been great. I keep forgetting someone might be actually reading this blog and forget to come back and review the comments.Beginning Blogger error, I guess.
I agree with you. I think the complications can be directly attributable to folks like me- consultants. For some reason, some conultants don't feel like good work and great products brought in on time and under budget is good enough. They need smoke and mirrors.
This is why I get so angry at the TLAs (Three Letter Abbreviations). They are nothing but marketing tools. There have only bee a few really deep changes in software development since the first fly got zapped in the Univac (or whatever it was called). And each was evolutionary rather than revolutionary- which is something the sales guys won't tell the customer.
1. Team-based developers- now we can do complicated and sophisticated things.
2. Importing Project Management methods from the construction and highway domain, Now there was somebody to yell at.
3. Waterfall Methodology- Can't say much for this, except it's Main Frame, central management thinking. But at least we could start reproducing our mistakes.
4. Iterative Methodology- the introduction of the BA from the bean counting department and Use Cases so changes can be made on paper rather than in the code. And we can do bigger and much more complicated stuff that won't work the way the business expected because no one reads those Use Case novels and just look at the pictures.
5. Agile Methodology- better, faster and business driven. Lots of good things,. A few bad things: a. It does not scale. Developers and team management need to be not only senior, but creative and at the top of their game, b. It requires a buy in by every member of the team- "we've never done it this way' is a very powerful human feeling and causes obstinacy. c. I've tried and tried to explain it in charts, diagrams and books. The senior, experienced folk see the advantages, but when the PM no longer manages and the BA no longer owns the documentation and developers actually have to talk to users takes some time getting use to. You really need to go through a complete SDLC before you really understand how it works,