Not too long ago, I was on a review team to look at an RFP (request for proposal) that had, more or less, come in over the transom.*
The project had its interesting points. The basic functionality was essentially a tracking application for custom jobs -- when did the job come in, who touched it last, what did they do with it, etc. It had to hook into a bigger system for planning and billing, but overall, it was fairly small. A routine RFP to evaluate, except for one thing.
This application only had about 15 functional screens plus a couple of administrative screens for login and user set-up. But the requirements document was over 400 pages. That works out to about 25 pages of requirements per screen.
Wow! must have been pretty complex functionality there. No, not really. The UI wasn't that much more complex than using the FedEx site to track a package or using Quicken to see how much you spent last week. So why such a big document?
It turns out each page was a table of about 15 rows, and most of the rows contained a statementnformation like this, "The title shall be Bold." "The logo shall be in the upper left." "The RGB value of the background shall be xxxx." One of my favorites was, "Clicking the Help icon shall open a pop-up window."
Needless to say, there was very little content in this document that explained the real business process behind these screens. And worse, all of these little details about fonts, color, cancelling when you click the Cancel button, etc. were repeated for every screen.
Instead of writing a tight 30-50 page document (or smaller) of very specific 2-3 page functional descriptions for each screen plus an appendix of universal design guidelines, the prospective client paid somebody to create this monster document. Can you figure out why?
Somebody had a big CYA concern.
In the accompanying RFP, was a handy "deliverables" chart with a line item mandating there would be a "Traceability Matrix". That is, somebody wanted to be sure you could match every detail in the requirements to detail in the code design, the code itself, the test plan and the test cases. Aye-yi-yi.
15 rows per page, 4 traces per row, 400 pages of requirements = 24,000 individual bits of information that somebody felt hadto be maintained over the life of this application.
You do not want to do it this way.
Trace if you like, but aggregate the common elements and design specs into one or two documents and check off the screens with a simple pass/fail. Turn the functional description of your screens into user stories or use cases and trace those to the screen that delivers the functionality. Turn thousands of little sentences into a few paragraphs or pages of meaningful content per screen and trace that. Check these chunks off pass/fail, add notes and rework when the grade is "fail". Don't let the Matrix control your project.
* slang for an unsolicited submission. Old-time office buildings often had small moveable windows over the main doors. Imagine someone chucking a bundle of pages through that window into an editor's office.
Tuesday, April 14, 2009
Tuesday, April 7, 2009
Throughput: How can I get more of it?
A while ago, a friend and I were comparing experiences on our projects. She talked a little about one of her key stakeholders and said, "He asked me how could he get more throughput out of his team. I didn't know exactly what to say."
Throughput, eh? The word calls to mind network traffic and bits and bytes of data streaming over cables or fiber optics. It's not too far of a jump to extrapolate that to manufacturing or industrial processes like gallons of oil pumped through pipelines or numbers of cargo containers moving through shipping terminals. You could imagine the term applied to fungible goods or relatively interchangeable units of stuff moving on assembly lines. But we were talking about software so what was interchangeable or fungible about that? Lines of code? Nope. Function points? Features? Well, maybe those things are countable. But to what end?
"So, what was he really thinking about?" I asked my friend. "Is he saying that it's taking too long to get a release delivered or is he saying that he's not seeing many significant changes in the releases?"
"Well, both," she said.
"Ahh. I see. What you have there is either a process problem or a people problem or both. And whichever it is, you have the wrong thing and probably too much of it."
If it takes too long between releases, you have a process problem and you probably have too much process -- too many steps, checkpoints, sign-offs, etc.
If you don't get much value out of a release, you have a people problem. The wrong people are making decisions or you are not talking to the right people to get ideas.
Change the process, change the people and throughput should improve.
Throughput, eh? The word calls to mind network traffic and bits and bytes of data streaming over cables or fiber optics. It's not too far of a jump to extrapolate that to manufacturing or industrial processes like gallons of oil pumped through pipelines or numbers of cargo containers moving through shipping terminals. You could imagine the term applied to fungible goods or relatively interchangeable units of stuff moving on assembly lines. But we were talking about software so what was interchangeable or fungible about that? Lines of code? Nope. Function points? Features? Well, maybe those things are countable. But to what end?
"So, what was he really thinking about?" I asked my friend. "Is he saying that it's taking too long to get a release delivered or is he saying that he's not seeing many significant changes in the releases?"
"Well, both," she said.
"Ahh. I see. What you have there is either a process problem or a people problem or both. And whichever it is, you have the wrong thing and probably too much of it."
If it takes too long between releases, you have a process problem and you probably have too much process -- too many steps, checkpoints, sign-offs, etc.
If you don't get much value out of a release, you have a people problem. The wrong people are making decisions or you are not talking to the right people to get ideas.
Change the process, change the people and throughput should improve.
Friday, April 3, 2009
Scouting for players: What's their comfort zone?
Last night Paul, my long-time partner, and I had dinner at our local Irish pub. The last of the NIT championship game was on the big screen followed by the NCAA 3-point championship.
Now, the 3-point championship doesn't mean that much. Mainly it's a way for players whose teams didn't make the Final Four to get a little more publicity for their schools and get a little more personal attention from pro scouts and coaches. Still, it's an interesting diversion to watch because it's not easy to consistently sink long baskets from the 3-point perimeter when you're just horsing around. Make it a championship and you have something that simulates the pressure of making the game-winning shot in the final seconds of the game. Do it four or five times in a row while dashing around the court and it can be pretty impressive.
To succeed, you have to get into a mental zone that puts you on automatic pilot, instinctively executing the right stance, the right wrist move, the right head turn to the basket that will send the ball -- swoosh -- through and not -- bonk -- off the rim. One guy caught our attention in the first round as the person who seemed the most relaxed into that shot-making groove. As the elimination rounds proceeded, I also noticed that he was demonstrating some really good sportmanship moves on the sidelines.
He genuinely seemed to be rooting for his competitors, shaking hands, patting backs, doing guy-hugs; talking and engaging with the other players in a "big-happy-family" kind of way. I pointed this out to Paul and said that if I were a scout I might be looking at him as a good team player.
Paul and I talked about this for quite a while. Traits and tip-offs that we had seen or read about or heard from others that were good clues you may or may not want to work with a person.
Our guy ended up winning the shoot-out fairly easily 22-17 and the women's champion won her title by the same dominant margin, 19-14. Then of course, it was the battle of the sexes, Men's champion vs. Women's champion. Here's where it got interesting.
It was close, but our guy won 17-15. And when the woman's last shot bounced off the rim, the camera caught him doing the most exaggerated head-shaking, shoulder-waggling, hip-shimmying, "dance-on-the-grave-of-my-enemy" celebration you could imagine. It was so insulting....What happened to Mr. Good Sportsman, I wondered?
Paul hit on it right away. "The risks were too high. He could have been beaten by a girl."
Competing against other men, our guy was in his comfort zone; all the learned patterns about cameraderie and sportmanship were flowing in the zone. There was not much to lose if he lost to another one of the guys. But when the stakes shifted, the zone broke down and the behavior shifted with it.
It's an interesting thing to keep in mind when you're scouting talent for your team.
Now, the 3-point championship doesn't mean that much. Mainly it's a way for players whose teams didn't make the Final Four to get a little more publicity for their schools and get a little more personal attention from pro scouts and coaches. Still, it's an interesting diversion to watch because it's not easy to consistently sink long baskets from the 3-point perimeter when you're just horsing around. Make it a championship and you have something that simulates the pressure of making the game-winning shot in the final seconds of the game. Do it four or five times in a row while dashing around the court and it can be pretty impressive.
To succeed, you have to get into a mental zone that puts you on automatic pilot, instinctively executing the right stance, the right wrist move, the right head turn to the basket that will send the ball -- swoosh -- through and not -- bonk -- off the rim. One guy caught our attention in the first round as the person who seemed the most relaxed into that shot-making groove. As the elimination rounds proceeded, I also noticed that he was demonstrating some really good sportmanship moves on the sidelines.
He genuinely seemed to be rooting for his competitors, shaking hands, patting backs, doing guy-hugs; talking and engaging with the other players in a "big-happy-family" kind of way. I pointed this out to Paul and said that if I were a scout I might be looking at him as a good team player.
Paul and I talked about this for quite a while. Traits and tip-offs that we had seen or read about or heard from others that were good clues you may or may not want to work with a person.
Our guy ended up winning the shoot-out fairly easily 22-17 and the women's champion won her title by the same dominant margin, 19-14. Then of course, it was the battle of the sexes, Men's champion vs. Women's champion. Here's where it got interesting.
It was close, but our guy won 17-15. And when the woman's last shot bounced off the rim, the camera caught him doing the most exaggerated head-shaking, shoulder-waggling, hip-shimmying, "dance-on-the-grave-of-my-enemy" celebration you could imagine. It was so insulting....What happened to Mr. Good Sportsman, I wondered?
Paul hit on it right away. "The risks were too high. He could have been beaten by a girl."
Competing against other men, our guy was in his comfort zone; all the learned patterns about cameraderie and sportmanship were flowing in the zone. There was not much to lose if he lost to another one of the guys. But when the stakes shifted, the zone broke down and the behavior shifted with it.
It's an interesting thing to keep in mind when you're scouting talent for your team.
Wednesday, April 1, 2009
An interesting development in Finland
I think that in America we recognize there's a benefit to the intersection of business and technology and many of our leading universities assemble programs that attempt to foster a path between science/technology and management but we are generally late to the party when it comes to understanding design and innovation.
Now, from the Financial Times of March 29, 2009 comes this piece of news:
"Across the world, business people, creative types and technology geeks struggle to understand each other. Their education and training, even much of their work, is carried out in separate silos, with exciting collaborations the exception rather than the rule.
"Now Helsinki’s business school, art college and technology school have come up with a radical plan: a three-way merger to create what they claim will be a unique, integrated seedbed for innovation. The new institution, Aalto University, will offer joint courses later this year and will be open fully at the beginning of 2010 as the flagship project in a national shake-up of higher education."
Among the educators behind this venture is a Professor Ekman who says, "There are certain fields of technology, design and business where we cannot live without each other and this has been true for the last 15 years or so....there will be a real world pay-off in learning through project-based, problem-solving study to respect and communicate and co-operate with professionals who have different mindsets."
You can read the full article here.
Now, from the Financial Times of March 29, 2009 comes this piece of news:
"Across the world, business people, creative types and technology geeks struggle to understand each other. Their education and training, even much of their work, is carried out in separate silos, with exciting collaborations the exception rather than the rule.
"Now Helsinki’s business school, art college and technology school have come up with a radical plan: a three-way merger to create what they claim will be a unique, integrated seedbed for innovation. The new institution, Aalto University, will offer joint courses later this year and will be open fully at the beginning of 2010 as the flagship project in a national shake-up of higher education."
Among the educators behind this venture is a Professor Ekman who says, "There are certain fields of technology, design and business where we cannot live without each other and this has been true for the last 15 years or so....there will be a real world pay-off in learning through project-based, problem-solving study to respect and communicate and co-operate with professionals who have different mindsets."
You can read the full article here.
Subscribe to:
Posts (Atom)