I stumbled upon the book "The Machine that Changed the World" about Toyota's Lean Engineering Processes. A comparison has been made between auto manufacturing processes and software engineering and there are now movements in lean software engineering.
I thought auto makers still did it the way Henry Ford did it. Turns out in the 1950s, Toyota revolutionized the whole thing. They were able to come out with cars 3 years before their competition and $2000 cheaper!
There is a lesson here for the software community. We need to embrace agile or lean thinking or our discipline will become staid. I think there's a human tendency to always move on to the next best thing. Work on one thing, do a good job and move on to the next. However, people don't stick around and make sure that 'good thing' is actually good. Is it being executed on a daily basis or according to plan? Maybe it needs course corrections.
I'm jumbling a lot of things in this one post so excuse the rambling. I'll sort it all out at some point.
Ideas for metrics:
1) # of unit tests written? are they growing as software is growing? Are they being executed in the nightly batch? <- refers more to adoption of TDD
2) Are we able to auto-generate documentation? [ I'm not familiar with what's out there but if we go agile and give precedence to writing code, a tool like this may satisfy those documentation hounds ]
Saturday, December 15, 2007
Friday, November 30, 2007
Books
I've been interested in a few business books of late:
1) Crossing the Chasm: This book is good but a little dry. I almost put it away for good a few times but I persevered and made it 3/4 of the way in. The distribution/pricing chapter got to me though. I had no idea what he was talking about. However, there are some seminal ideas in this book overall.
A lot of these techniques/ideas can be applied on a smaller scale; for instance, in my own position as an analyst pushing out a new product so we get more users.
2) Execution: The Discipline of Getting Things Done
I haven't yet read this book but it's on my queue. Even before I heard of the book, it came to me in a flash that the single biggest obstacle to success is lack of execution. Every Tom, Dick & Harry has a new plan, a new strategy that if they get their way and implement, then things would work out. But give Tom, Dick or Harry that chance, and you'll see 9 times out of 10, they'll kick the strategy off, give a few high level commands and assume it's done. They'll then move on to other areas where they can tout other high-level strategic initiatives. Tom, Dick & Harry have no follow-through. They think their jobs are done and move on to conquer the rest of the world. The sad reality is that without the actual will to implement, enforce and measure, their strategies end up being only mere words and now Ray, Jim & Frank are waiting in the wings to kick off their own set of initiatives. And here we go again...
1) Crossing the Chasm: This book is good but a little dry. I almost put it away for good a few times but I persevered and made it 3/4 of the way in. The distribution/pricing chapter got to me though. I had no idea what he was talking about. However, there are some seminal ideas in this book overall.
A lot of these techniques/ideas can be applied on a smaller scale; for instance, in my own position as an analyst pushing out a new product so we get more users.
- He advocates the idea of creating user stories very similar to user profiles in usability testing.
- Whole product marketing is another concept that can be applied. If I tackle the beachhead users, I need to make sure I fulfill all their needs. They'll be my references so that I can move on and win my other customers.
- And of course, just deciding on the beachhead is a big decision. You need to FOCUS on which segment you want to win. You can't tackle all your customers at once.
2) Execution: The Discipline of Getting Things Done
I haven't yet read this book but it's on my queue. Even before I heard of the book, it came to me in a flash that the single biggest obstacle to success is lack of execution. Every Tom, Dick & Harry has a new plan, a new strategy that if they get their way and implement, then things would work out. But give Tom, Dick or Harry that chance, and you'll see 9 times out of 10, they'll kick the strategy off, give a few high level commands and assume it's done. They'll then move on to other areas where they can tout other high-level strategic initiatives. Tom, Dick & Harry have no follow-through. They think their jobs are done and move on to conquer the rest of the world. The sad reality is that without the actual will to implement, enforce and measure, their strategies end up being only mere words and now Ray, Jim & Frank are waiting in the wings to kick off their own set of initiatives. And here we go again...
Saturday, October 13, 2007
Culture of Discipline
Title stolen from a chapter in Jim Collins' book "Good To Great".
I had arranged for a demo of Agile development to our team and I thought maybe it was something that we could employ. However, to my dismay, one of our software practitioners (in fact he is one of the development managers) didn't like the process; he called it micro-management and claimed that his engineers would kill him if he tried something like that with them [in jest of course].
The process that was demonstrated was called SCRUM and it employs meetings every day asking developers what they did yesterday and what they're doing today. Moreover, this particular process asks for developers to enter their time spent doing development on a daily basis. It definitely involves more careful monitoring of people's time. However, this is an effective scheme for determining if software schedules will be met and for averting disaster. The bi-weekly or weekly status meetings don't cut it anymore. I can understand his point of view. I used to be a developer myself and probably would have hated to determine how long a task would take or be constantly asked how much time I spent on something everyday. [A little bit of "Don't tell me what to do"]
This needs to change if we're going to ever get good at software management. This is a culture change in the way of treating software engineers and asking them to change their behavior, i.e., to become more disciplined. As a software engineer, I was arrogant and cavalier. I prided myself on being an expert at C or C++ (or whatever it was I was doing) and any company should be glad to have me and my expertise. If I need to take as long as I took to get something done, then that's how much time it should have taken. Or if something wasn't done that should have been done, I was busy doing something else that was just as (if not even more) important. My time was my own; I didn't have to tell anyone what I was doing; and for the most part management didn't care. If I got things done a day early, no one had to know about it and I would surf the web and take it easy the next day. But that kind of attitude isn't how you build great software nor a great organization.
Micro-management is a dirty word. No manager probably wants to be called that. It's a death knell to be referred to as one. However, the truth of the matter is if you were to form new habits, you need to act as one. If you're losing weight, until you form the habit of watching what you're putting in your mouth, you will not lose weight. You need to micro-manage what you eat. If you're learning a new skill, you need to pay attention to the minutiae of each motion (e.g., swinging a tennis racket). Similarly, the same goes for management. If you're going to introduce new habits (or processes) within your team, you need to buckle down and enforce them until they become a habit. You need to micro-manage. If you're going to kick off a new process and expect your team to follow it, you're going to have to monitor and micro-manage them and quickly correct errors. This is a fact of life. Don't let the fear of being called a micro-manager deter you!
In fact, one of my most memorable experiences being 'micro-managed' was at a start-up company. A new senior executive had joined at a time when our product had fallen behind. This new exec quickly set up daily early morning meetings with key staff and a list of the issues. It was almost like a SCRUM meeting. He wanted updates on each issue and what progress was made since the previous day. At first I considered the meetings a pain. [I don't want to be at the office by 8 !!] It was intense, being in those meetings. You had to own up! And you knew what was expected of you at tomorrow's meeting. But after a while, as the issues were closed, one after another, and our software became mature, we really became cohesive as a team/company and felt proud that we were pulling together to put out a quality product. We eventually had a great product ready for the market. This guy did what his predecessor didn't do. His predecessor was hacking away at the weeds whereas this guy knew what needed to be done and did it. No surprise that he is now a Senior VP at IBM.
In fact, to really build an effective organization at all levels, that "micro-management" ethos needs to be practiced by every individual in the organization. Each individual needs to be disciplined enough to carry out his/her duties to the fullest. Jim Collins states: "People in the good-to-great companies became somewhat extreme in the fulfillment of their responsibilities, bordering in some cases on fanaticism". I liken micro-management to being present in each moment. If you're present in each moment of your life and fully engaged with what's going on, then you will fulfill your responsibilities. Or you will speak up and address something when it doesn't make sense and so on.
I had arranged for a demo of Agile development to our team and I thought maybe it was something that we could employ. However, to my dismay, one of our software practitioners (in fact he is one of the development managers) didn't like the process; he called it micro-management and claimed that his engineers would kill him if he tried something like that with them [in jest of course].
The process that was demonstrated was called SCRUM and it employs meetings every day asking developers what they did yesterday and what they're doing today. Moreover, this particular process asks for developers to enter their time spent doing development on a daily basis. It definitely involves more careful monitoring of people's time. However, this is an effective scheme for determining if software schedules will be met and for averting disaster. The bi-weekly or weekly status meetings don't cut it anymore. I can understand his point of view. I used to be a developer myself and probably would have hated to determine how long a task would take or be constantly asked how much time I spent on something everyday. [A little bit of "Don't tell me what to do"]
This needs to change if we're going to ever get good at software management. This is a culture change in the way of treating software engineers and asking them to change their behavior, i.e., to become more disciplined. As a software engineer, I was arrogant and cavalier. I prided myself on being an expert at C or C++ (or whatever it was I was doing) and any company should be glad to have me and my expertise. If I need to take as long as I took to get something done, then that's how much time it should have taken. Or if something wasn't done that should have been done, I was busy doing something else that was just as (if not even more) important. My time was my own; I didn't have to tell anyone what I was doing; and for the most part management didn't care. If I got things done a day early, no one had to know about it and I would surf the web and take it easy the next day. But that kind of attitude isn't how you build great software nor a great organization.
Micro-management is a dirty word. No manager probably wants to be called that. It's a death knell to be referred to as one. However, the truth of the matter is if you were to form new habits, you need to act as one. If you're losing weight, until you form the habit of watching what you're putting in your mouth, you will not lose weight. You need to micro-manage what you eat. If you're learning a new skill, you need to pay attention to the minutiae of each motion (e.g., swinging a tennis racket). Similarly, the same goes for management. If you're going to introduce new habits (or processes) within your team, you need to buckle down and enforce them until they become a habit. You need to micro-manage. If you're going to kick off a new process and expect your team to follow it, you're going to have to monitor and micro-manage them and quickly correct errors. This is a fact of life. Don't let the fear of being called a micro-manager deter you!
In fact, one of my most memorable experiences being 'micro-managed' was at a start-up company. A new senior executive had joined at a time when our product had fallen behind. This new exec quickly set up daily early morning meetings with key staff and a list of the issues. It was almost like a SCRUM meeting. He wanted updates on each issue and what progress was made since the previous day. At first I considered the meetings a pain. [I don't want to be at the office by 8 !!] It was intense, being in those meetings. You had to own up! And you knew what was expected of you at tomorrow's meeting. But after a while, as the issues were closed, one after another, and our software became mature, we really became cohesive as a team/company and felt proud that we were pulling together to put out a quality product. We eventually had a great product ready for the market. This guy did what his predecessor didn't do. His predecessor was hacking away at the weeds whereas this guy knew what needed to be done and did it. No surprise that he is now a Senior VP at IBM.
In fact, to really build an effective organization at all levels, that "micro-management" ethos needs to be practiced by every individual in the organization. Each individual needs to be disciplined enough to carry out his/her duties to the fullest. Jim Collins states: "People in the good-to-great companies became somewhat extreme in the fulfillment of their responsibilities, bordering in some cases on fanaticism". I liken micro-management to being present in each moment. If you're present in each moment of your life and fully engaged with what's going on, then you will fulfill your responsibilities. Or you will speak up and address something when it doesn't make sense and so on.
Effective Software Managers
Here's a link to a little blurb on being an effective software manager:
Effective Software Manager Blurb
and here's a link to the article the blurb also references:
What Makes an Effective Software Manager?
The author in the first link writes about his manager getting rid of ineffective people. This is really interesting because it's exactly the first thing Jim Collins writes about in "Good to Great": First, get the right people on the bus!
I also feel "Making the Call" [referenced in the two articles above] is incredibly important. I've found 'making the call' and 'taking ownership' go hand-in-hand. I'm seeing real-life examples where people who don't do so lead their employees in circles, running only to stand still and never without any sense of completion.
An example:
There is a service provided to us by an outside party and the contract was never signed. The service was executed nevertheless and the first quarter invoice for 2007 is still yet to be paid. Myriad attempts to get this invoice paid has led nowhere. I'm not sure who was responsible for dropping the ball. I do know there were many attempts by IT to pay the invoice. In addition, the contract was never signed for this service and this has been outstanding for almost a year. An email that I had sent out regarding the matter was never responded to. It would be amazing for a change to hear someone say, "OK, great. Let me look at that contract, sign it and hand it right back to you" and for them to actually do it. Instead, unreturned emails and phone calls are the norm. If my business user would 'make the call' or 'take ownership' this would make mine and many employees' lives easier. Instead, the issue gets buried until the next go-round.
I think in an environment like the bank where IT serves its business users and IT has traditionally acted subservient to the business, making the call is especially important. Many IT people I've seen don't want to challenge their business users and state their terms. Instead, they're led astray by business users who have no IT knowledge. I've actually found that when I grab the reigns and state unequivocally what the options are and what the challenges are of each option, then usually the business will comply. After all, we serve their interests. Why shouldn't they trust us? In fact, IT can be in a position where we can actually LEAD the business. However, when we are too eager to please or afraid to be clear about our intent, communication breaks down and we (IT) can be sent off on wild goose chases; goose chases, we might be resentful about, because we weren't clear from the get-go and because we were afraid to be straight with our users.
Effective Software Manager Blurb
and here's a link to the article the blurb also references:
What Makes an Effective Software Manager?
The author in the first link writes about his manager getting rid of ineffective people. This is really interesting because it's exactly the first thing Jim Collins writes about in "Good to Great": First, get the right people on the bus!
I also feel "Making the Call" [referenced in the two articles above] is incredibly important. I've found 'making the call' and 'taking ownership' go hand-in-hand. I'm seeing real-life examples where people who don't do so lead their employees in circles, running only to stand still and never without any sense of completion.
An example:
There is a service provided to us by an outside party and the contract was never signed. The service was executed nevertheless and the first quarter invoice for 2007 is still yet to be paid. Myriad attempts to get this invoice paid has led nowhere. I'm not sure who was responsible for dropping the ball. I do know there were many attempts by IT to pay the invoice. In addition, the contract was never signed for this service and this has been outstanding for almost a year. An email that I had sent out regarding the matter was never responded to. It would be amazing for a change to hear someone say, "OK, great. Let me look at that contract, sign it and hand it right back to you" and for them to actually do it. Instead, unreturned emails and phone calls are the norm. If my business user would 'make the call' or 'take ownership' this would make mine and many employees' lives easier. Instead, the issue gets buried until the next go-round.
I think in an environment like the bank where IT serves its business users and IT has traditionally acted subservient to the business, making the call is especially important. Many IT people I've seen don't want to challenge their business users and state their terms. Instead, they're led astray by business users who have no IT knowledge. I've actually found that when I grab the reigns and state unequivocally what the options are and what the challenges are of each option, then usually the business will comply. After all, we serve their interests. Why shouldn't they trust us? In fact, IT can be in a position where we can actually LEAD the business. However, when we are too eager to please or afraid to be clear about our intent, communication breaks down and we (IT) can be sent off on wild goose chases; goose chases, we might be resentful about, because we weren't clear from the get-go and because we were afraid to be straight with our users.
Saturday, October 6, 2007
Metrics
We use MQC (Mercury Quality Center) to store our defects and enhancements. We have about a year's worth of data in there and no one has thought to look and see what it tells us. I recently undertook such an effort. I export ALL defects/enhancements from MQC into an Excel file which is then parsed by an Access Database. I then wrote various queries to examine the data.
Here are some metrics that I want to examine after each release of our software to see how we are doing:
1) # of Outstanding Defects as of completion of this release ; broken down by severity and what version they were found in [to see how long they've been lying around]
2) # of Outstanding Enhancements to be implemented; broken down by priority and when they were requested [to see how long they've been lying around]
3) Breakdown of Defects/Enhancements for this latest release by Component to see which component of the software was touched the most.
4) Average [Mean, Median, & mode] Time to Fix a Defect [Critical, High, Medium, Low] until now
5) Average [Mean, Median & mode] Time to Implement a New Request [Critical, High, Medium, Low] until now
NOTE: If we apply Metrics 4 & 5 after each release, we can see if the average decreases over time to see if we're getting faster at delivering fixes and enhancements.
These metrics are pretty simple but will give us terrific information on where we are and what we need to work on to improve our process.
Here are some metrics that I want to examine after each release of our software to see how we are doing:
1) # of Outstanding Defects as of completion of this release ; broken down by severity and what version they were found in [to see how long they've been lying around]
2) # of Outstanding Enhancements to be implemented; broken down by priority and when they were requested [to see how long they've been lying around]
3) Breakdown of Defects/Enhancements for this latest release by Component to see which component of the software was touched the most.
4) Average [Mean, Median, & mode] Time to Fix a Defect [Critical, High, Medium, Low] until now
5) Average [Mean, Median & mode] Time to Implement a New Request [Critical, High, Medium, Low] until now
NOTE: If we apply Metrics 4 & 5 after each release, we can see if the average decreases over time to see if we're getting faster at delivering fixes and enhancements.
These metrics are pretty simple but will give us terrific information on where we are and what we need to work on to improve our process.
Friday, October 5, 2007
Support from the Top
If Bosses, Line Managers & PMs made it clear they want to see:
1) Burndown charts where they can see the progress to date vs. what was originally planned. And that they expect to see progress every day. This means that even if the manager doesn't have time for a status meeting today, if they wanted to see one s/he should be able to. It should be updated daily in accordance with what was accomplished. Management needs to catch errors early and to see if a project is going off-course in order to be pro-active.
As with daily scrum meetings, why not have a scrum-like managerial meeting where a burndown chart is presented and progress to-date is discussed, progress to-be-made is discussed and obstacles are presented?
2) Working software after each iteration! This is the only true measure of progress! Managers should ask that the software be demo'ed after each iteration.
more projects would be delivered on-time and on-budget! More users would be happy.
1) Burndown charts where they can see the progress to date vs. what was originally planned. And that they expect to see progress every day. This means that even if the manager doesn't have time for a status meeting today, if they wanted to see one s/he should be able to. It should be updated daily in accordance with what was accomplished. Management needs to catch errors early and to see if a project is going off-course in order to be pro-active.
As with daily scrum meetings, why not have a scrum-like managerial meeting where a burndown chart is presented and progress to-date is discussed, progress to-be-made is discussed and obstacles are presented?
2) Working software after each iteration! This is the only true measure of progress! Managers should ask that the software be demo'ed after each iteration.
more projects would be delivered on-time and on-budget! More users would be happy.
Wednesday, October 3, 2007
Some Agile Practices
Agile Practices that I'm thinking of implementing and as adapted to the environment I work in.
1) Have daily meeting for 10 minutes; Being agile requires open communication; everyone should know what's going on all the time.
Each person states:
a. What s/he accomplished yesterday
b. What s/he's going to do today
c. Any pain points/issues/obstacles
2) Have a process improvement meeting every month or even bi-weekly in the beginning
a. Figure out what's working/not working in the process and make adjustments
3) The BA should be available as development proceeds in each iteration to answer questions that come up and to test. This happens naturally in practice anyway. Much as we prefer a complete spec up-front (which few people read anyway), we should be honest about what the actual process is. Do we want to spend time developing the best spec ever up-front or proceed with Just Good enough requirements and start coding so we get working software?
These questions can be asked in a one-off basis (developer calls BA) or during the short, daily status meeting.
4) Use Burndown charts rather than project plans to track progress. Burndown charts are effective and especially look good to management because you can compare your original estimate to how you're actually doing. You can absorb all kinds of info including your 'velocity', where you hit bumps in the road, etc. Traditional project plans do not offer this because you just keep overwriting the same plan over and over with the latest dates. The n-th plan, after it is updated, looks like it was supposed to happen by design when in reality, you made it conform to the current status of the project. There is no way to compare the n-th plan to the 1st plan to show you how close you were to your estimates. And if you can't do this, how are you going to improve your process? Process Improvement depends on measurement and re-measurement! [I know people will object and say MS Project allows you to do such and such; and this might be true but to date, I haven't found anyone who uses this feature.]
5) Iterative Development and scheduling by feature delivery rather than Initiation, Definition, Design, etc.
6) Get estimates based on time to implement features rather than Initiation, Definition, Design, etc. These estimates would likely be more accurate and something developers can give and live up to.
7) Deploy prototypes and let developers have a go at them to give feedback so you can make it even more bulletproof and to also advertise to them what's coming. Prototypes help developers get familiar with upcoming changes and new features and will enable them to give better estimates on implementation time after playing with a prototype. Prototypes also act as requirements specifications in and of themselves. Rather than have a developer wade through a huge specification document, s/he can fire up the prototype and see the actual behavior demonstrated! A prototype is worth a thousand pages [of requirements documents]!
8) After incorporating feedback from the Dev team, I would go show my users. The prototype needn't do everything. It's a good idea to storyboard a typical scenario and walk the user through it and paint a picture. Picture a child enraptured by a parent telling a story. You want to fully engage the user with a prototype and have s/he contribute meaningful feedback.
1) Have daily meeting for 10 minutes; Being agile requires open communication; everyone should know what's going on all the time.
Each person states:
a. What s/he accomplished yesterday
b. What s/he's going to do today
c. Any pain points/issues/obstacles
2) Have a process improvement meeting every month or even bi-weekly in the beginning
a. Figure out what's working/not working in the process and make adjustments
3) The BA should be available as development proceeds in each iteration to answer questions that come up and to test. This happens naturally in practice anyway. Much as we prefer a complete spec up-front (which few people read anyway), we should be honest about what the actual process is. Do we want to spend time developing the best spec ever up-front or proceed with Just Good enough requirements and start coding so we get working software?
These questions can be asked in a one-off basis (developer calls BA) or during the short, daily status meeting.
4) Use Burndown charts rather than project plans to track progress. Burndown charts are effective and especially look good to management because you can compare your original estimate to how you're actually doing. You can absorb all kinds of info including your 'velocity', where you hit bumps in the road, etc. Traditional project plans do not offer this because you just keep overwriting the same plan over and over with the latest dates. The n-th plan, after it is updated, looks like it was supposed to happen by design when in reality, you made it conform to the current status of the project. There is no way to compare the n-th plan to the 1st plan to show you how close you were to your estimates. And if you can't do this, how are you going to improve your process? Process Improvement depends on measurement and re-measurement! [I know people will object and say MS Project allows you to do such and such; and this might be true but to date, I haven't found anyone who uses this feature.]
5) Iterative Development and scheduling by feature delivery rather than Initiation, Definition, Design, etc.
6) Get estimates based on time to implement features rather than Initiation, Definition, Design, etc. These estimates would likely be more accurate and something developers can give and live up to.
7) Deploy prototypes and let developers have a go at them to give feedback so you can make it even more bulletproof and to also advertise to them what's coming. Prototypes help developers get familiar with upcoming changes and new features and will enable them to give better estimates on implementation time after playing with a prototype. Prototypes also act as requirements specifications in and of themselves. Rather than have a developer wade through a huge specification document, s/he can fire up the prototype and see the actual behavior demonstrated! A prototype is worth a thousand pages [of requirements documents]!
8) After incorporating feedback from the Dev team, I would go show my users. The prototype needn't do everything. It's a good idea to storyboard a typical scenario and walk the user through it and paint a picture. Picture a child enraptured by a parent telling a story. You want to fully engage the user with a prototype and have s/he contribute meaningful feedback.
Sunday, September 30, 2007
Types of Projects
This is an attempt to classify different types of IT projects that happen on the Street.
1) Projects that are demanded by stakeholders: perhaps to support a new business or for regulatory/auditing purposes, etc).
Basically the business is hot for these projects. They demand them to be highest priority. These projects are necessarily agile and driven by stakeholders. Delivery is so tight and fast that stakeholders may even go straight to developers to discuss their needs. A BA may or may not be involved.
The pros:
2) Strategic Projects driven by IT
The way IT implements strategic solutions is long and cumbersome, falling back on a waterfall, BRUF (Big Requirements Up Front) approach. Stakeholders don't see value and in the interim, come back with more tactical projects that drive project plans and resources off-course. This type of project needs strong motivation and vision in IT. The initiative for this is most likely spawned by IT and sold to the business as a 'game-changer'. The threat here comes from being derailed by stakeholder demands for other projects (either because some other requirements arise or because they haven't seen any value come from the time/money spent so far).
The BRUF/Waterfall method is especially a threat to these IT driven strategic projects because of IT's tendency to want to do it right the first time. Months may go by without the stakeholders seeing a single screen and giving their feedback on the direction of the project. Without something tangible to go back to the business with to elicit real feedback, the development team may dream up something that is completely orthogonal or irrelevant to what is actually needed by end-users.
And when the system is actually delivered (most likely many, many months later), enthusiasm has waned and the system is so off-base from what was sold to the stakeholders that it is deemed un-usable or obsolete.
The biggest impediment to these types of projects is lack of stakeholder participation. Steps to combat this are:
1) Decrease time between 'selling the system to stakeholders' and delivery of a working system (even if its initial feature-set is limited)
2) Iterative Development and prototyping and involving stakeholders at each and every stage.
1) Projects that are demanded by stakeholders: perhaps to support a new business or for regulatory/auditing purposes, etc).
Basically the business is hot for these projects. They demand them to be highest priority. These projects are necessarily agile and driven by stakeholders. Delivery is so tight and fast that stakeholders may even go straight to developers to discuss their needs. A BA may or may not be involved.
The pros:
- Gives the users exactly what they want, no more and no less
- Business feels IT is responsive to their needs
- Business babble <-> Techno babble translation process (without a BA) may have some glitches, but feedback is fast and there is far less opportunity to go astray and deliver unneeded functionality
- Sometimes IT may run into a business user who dictates the technological solution rather than just give requirements. And who might also quickly and violently change requirements. In this case, it might be very hard for IT to push-back. One strategy that is being implemented in just such a case is to have the business user deliver his requests in batches. Anything making a certain cutoff time will be implemented and anything afterwards will make it in the next day. Another strategy is for IT to "cost" the list of remaining work items [i.e., Item 1 will take 3 hours, Item 2 will take 4 hours, etc] and have the Business User prioritize them himself. He'll know exactly what he's getting and when. He might even slow his requests down :)
2) Strategic Projects driven by IT
The way IT implements strategic solutions is long and cumbersome, falling back on a waterfall, BRUF (Big Requirements Up Front) approach. Stakeholders don't see value and in the interim, come back with more tactical projects that drive project plans and resources off-course. This type of project needs strong motivation and vision in IT. The initiative for this is most likely spawned by IT and sold to the business as a 'game-changer'. The threat here comes from being derailed by stakeholder demands for other projects (either because some other requirements arise or because they haven't seen any value come from the time/money spent so far).
The BRUF/Waterfall method is especially a threat to these IT driven strategic projects because of IT's tendency to want to do it right the first time. Months may go by without the stakeholders seeing a single screen and giving their feedback on the direction of the project. Without something tangible to go back to the business with to elicit real feedback, the development team may dream up something that is completely orthogonal or irrelevant to what is actually needed by end-users.
And when the system is actually delivered (most likely many, many months later), enthusiasm has waned and the system is so off-base from what was sold to the stakeholders that it is deemed un-usable or obsolete.
The biggest impediment to these types of projects is lack of stakeholder participation. Steps to combat this are:
1) Decrease time between 'selling the system to stakeholders' and delivery of a working system (even if its initial feature-set is limited)
2) Iterative Development and prototyping and involving stakeholders at each and every stage.
Why, oh why, Waterfall?
Many of the projects in IT on Wall Street don't seem like they're developed 'agile-ly'. PMs, BAs and developers still have waterfall ideas in mind.
This goes against all common sense: (1) It is well documented that the waterfall system is an extremely poor approach to developing useful systems to stakeholders, and (2) in an arena like Investment Banking, where Time to Market is usually "need to have it yesterday", waterfall is completely the wrong way to go.
There's something about the human psyche that gravitates towards using a waterfall approach: possibly the desire to have things wrapped in packages with a bowtie so that it can be deemed complete. I'll complete the requirements, hand it over to the architect who will then complete the design and then hand it over to the developers who will then hand it over to QA. [QA of course gets short-shrift in all this].
Blame Henry Ford and his assembly-line :) Of course there's a huge difference between assembling a car (or any manufactured product) off the assembly line and developing software. By the time the car or toy or whatever product it is hits the assembly line, prototypes have been constructed already, focus groups have been interviewed, potential users have been approached, etc. Do we do this with software? I've seen it happen on projects where prototypes are not even created and shopped around to end users for their feedback.
The assembly line is just not the best analogy for building software...
This goes against all common sense: (1) It is well documented that the waterfall system is an extremely poor approach to developing useful systems to stakeholders, and (2) in an arena like Investment Banking, where Time to Market is usually "need to have it yesterday", waterfall is completely the wrong way to go.
There's something about the human psyche that gravitates towards using a waterfall approach: possibly the desire to have things wrapped in packages with a bowtie so that it can be deemed complete. I'll complete the requirements, hand it over to the architect who will then complete the design and then hand it over to the developers who will then hand it over to QA. [QA of course gets short-shrift in all this].
Blame Henry Ford and his assembly-line :) Of course there's a huge difference between assembling a car (or any manufactured product) off the assembly line and developing software. By the time the car or toy or whatever product it is hits the assembly line, prototypes have been constructed already, focus groups have been interviewed, potential users have been approached, etc. Do we do this with software? I've seen it happen on projects where prototypes are not even created and shopped around to end users for their feedback.
The assembly line is just not the best analogy for building software...
The Nature of IT on Wall Street
It may seem business users are fickle, that they want and demand a system that does X, but then when it's delivered, they never use it. That could be attributed to a variety of reasons: (1) perhaps the requirements gathering exercise went awry (i.e., the system doesn't do what they wanted it to do), (2) usability is horrible, or (3) their needs have changed; possibly because the system took too long to deliver and they've adapted their business processes and need something new or even nothing at all.
The above are just a smattering of reasons, and definitely not all-encompassing. However, working on Wall Street (and I'm not talking just about IT) is a risky proposition. Talk to 1st year analysts about waste. These people sit on the front lines and put in 15 hour days and 90 hour weeks. Some of their tasks entail creating Powerpoint presentations, creating reports, binding books, etc. in painstaking detail and constant revision. And you know what? Sometimes, they're never even used. It's no wonder then that this 'waste' trickles over to the IT side. The business is apparently 'fickle' all on its own.
We in IT want to so desperately get it right. We want to have perfect requirements, requirements that don't change, so we can move to design and then software construction without any hiccups. Change bothers us which is ironic because technology is all about change!
We want to manage projects in classic waterfall fashion where we're absolutely finished with requirements which we can then hand over to our architects who will then create an architecture/design which can then be handed over to developers and so on. Change disrupts this.
We need to get away from this line of thinking. We need to welcome change. We need to be adaptable. And if there's waste going on with our business users, it sure as hell is going to happen in IT. Denying this is futile. Waste WILL happen. But the term 'waste' is really a misnomer. It's not waste if it helps us move towards a goal. It's an avenue we explore but then realize that it's not the right one. That's what it really is.
Edison once said: I have not failed. I've just found 10,000 ways that won't work.
Case in point: I've heard that Apple creates zillions of prototypes and goes through very rigorous testing to ensure that only the highest quality product goes out (in terms of usability, customer appeal, design, etc). Would these zillions of prototypes be considered waste? Not when you consider what Apple has achieved! They are true innovators and it takes incredible zeal and innovation to get there. But also a freedom from the fear of not having to do it right the first time.
So those prototypes or that first release of the software that you don't want to develop until the requirements are fully in, forget it. Your best bet is to go ahead and develop it so you can use it to elicit even better requirements from your users and build relationships with your stakeholders.
The above are just a smattering of reasons, and definitely not all-encompassing. However, working on Wall Street (and I'm not talking just about IT) is a risky proposition. Talk to 1st year analysts about waste. These people sit on the front lines and put in 15 hour days and 90 hour weeks. Some of their tasks entail creating Powerpoint presentations, creating reports, binding books, etc. in painstaking detail and constant revision. And you know what? Sometimes, they're never even used. It's no wonder then that this 'waste' trickles over to the IT side. The business is apparently 'fickle' all on its own.
We in IT want to so desperately get it right. We want to have perfect requirements, requirements that don't change, so we can move to design and then software construction without any hiccups. Change bothers us which is ironic because technology is all about change!
We want to manage projects in classic waterfall fashion where we're absolutely finished with requirements which we can then hand over to our architects who will then create an architecture/design which can then be handed over to developers and so on. Change disrupts this.
We need to get away from this line of thinking. We need to welcome change. We need to be adaptable. And if there's waste going on with our business users, it sure as hell is going to happen in IT. Denying this is futile. Waste WILL happen. But the term 'waste' is really a misnomer. It's not waste if it helps us move towards a goal. It's an avenue we explore but then realize that it's not the right one. That's what it really is.
Edison once said: I have not failed. I've just found 10,000 ways that won't work.
Case in point: I've heard that Apple creates zillions of prototypes and goes through very rigorous testing to ensure that only the highest quality product goes out (in terms of usability, customer appeal, design, etc). Would these zillions of prototypes be considered waste? Not when you consider what Apple has achieved! They are true innovators and it takes incredible zeal and innovation to get there. But also a freedom from the fear of not having to do it right the first time.
So those prototypes or that first release of the software that you don't want to develop until the requirements are fully in, forget it. Your best bet is to go ahead and develop it so you can use it to elicit even better requirements from your users and build relationships with your stakeholders.
More thoughts on Customer Service
When people jump up and down for you, cater to your needs, pay attention to you, drop what they're doing to attend to you, now that's customer service!
Ever encounter one of these cashiers at Target or Home Depot? How they take their own sweet time to even look at you when you come up to their counter? And make it seem like they're doing you a favor by even talking to you. That's anti customer-service!
When a person makes you feel excited and welcome for doing business with them and even interacting with them (when you might not even buy anything from them at that moment), that's what brings customers back. It's the experience. Starbucks for example has gone beyond coffee and delivers the Starbucks experience.
The key is to underpromise and overdeliver. I manage a book of work and have clients who make requests for new features, new data and bug fixes. One colleague who was previously managing the book of work is of the "create dev ticket -> prioritize -> develop" mentality. Sounds fair; sounds like the norm. However, he had created a ticket just for the sole purpose of removing a departed colleague's e-mail address from a configuration file. And then it had to be prioritized and assigned to someone else on the team. I was in disbelief! Removing an email address from a config file takes 30 seconds. Creating a ticket was a waste of time; and then assigning the ticket was a waste of time. He could have just edited the file and been done with it.
Looking for ways to put in the extra mile makes the difference between an average business and a superior business. I've made it my mission in business and in life to see where I can make a difference; where I can go that extra mile and make a client happy. As a manager I would do that extra 'mundane' work so that I can avoid giving it to a developer who wants to do some thing niftier. I have no problem with that. Management is about keeping people happy and satisfied so they continue to do a good job, after all.
Ever encounter one of these cashiers at Target or Home Depot? How they take their own sweet time to even look at you when you come up to their counter? And make it seem like they're doing you a favor by even talking to you. That's anti customer-service!
When a person makes you feel excited and welcome for doing business with them and even interacting with them (when you might not even buy anything from them at that moment), that's what brings customers back. It's the experience. Starbucks for example has gone beyond coffee and delivers the Starbucks experience.
The key is to underpromise and overdeliver. I manage a book of work and have clients who make requests for new features, new data and bug fixes. One colleague who was previously managing the book of work is of the "create dev ticket -> prioritize -> develop" mentality. Sounds fair; sounds like the norm. However, he had created a ticket just for the sole purpose of removing a departed colleague's e-mail address from a configuration file. And then it had to be prioritized and assigned to someone else on the team. I was in disbelief! Removing an email address from a config file takes 30 seconds. Creating a ticket was a waste of time; and then assigning the ticket was a waste of time. He could have just edited the file and been done with it.
Looking for ways to put in the extra mile makes the difference between an average business and a superior business. I've made it my mission in business and in life to see where I can make a difference; where I can go that extra mile and make a client happy. As a manager I would do that extra 'mundane' work so that I can avoid giving it to a developer who wants to do some thing niftier. I have no problem with that. Management is about keeping people happy and satisfied so they continue to do a good job, after all.
Monday, September 3, 2007
Parkinson's Law
I found this on Wikipedia when I was searching for the phrase: If you want something done, give it to a busy person.
Parkinson's Law states that "work expands so as to fill the time available for its completion." A more succinct phrasing also commonly used is "work expands to fill the time available." or in computer-ese, "Data expands to fill the space available for storage".
Note the first thing about Project management above: This means we can never finish projects early or even on time!
There is controversy surrounding Wikipedia and how accurate its entries are but it sure sounds convincing. Is it true? It seems that way from personal experience at work. Software features need to be dropped in order to meet deadlines.
Parkinson's Law states that "work expands so as to fill the time available for its completion." A more succinct phrasing also commonly used is "work expands to fill the time available." or in computer-ese, "Data expands to fill the space available for storage".
Application of Parkinson's Law
Parkinson's Law is applied in many arenas of human endeavor.
- In Project Management, individual tasks with end dates rarely finish early because the people doing the work expand the work to finish approximately at the end date. Coupled with the Student syndrome, individual tasks are nearly guaranteed to be late.
- Individuals see this arise in their daily activities as well. No matter how many things one has on their plate, they all tend to get done. This leads to the canard, "If you want something done, give it to a busy person" because it appears they are better at "time management." While this may be true, it is just that they are doing more and the work is not expanding indefinitely to fill non-busy time.
- As an individuals income rises, their costs of living and lifestyle increases to meet their income level.
Note the first thing about Project management above: This means we can never finish projects early or even on time!
There is controversy surrounding Wikipedia and how accurate its entries are but it sure sounds convincing. Is it true? It seems that way from personal experience at work. Software features need to be dropped in order to meet deadlines.
A Thing called Transformation
I wrote this letter about transformation and how it's changed my life to a columnist in the NY Times a few months ago. I wanted to reprint an excerpt here.
...
I wanted to share with you my own story of how I transitioned from
working at home to enjoying work in the corporate world. I was in
consulting work briefly so I spent a lot of time working from home
and, at first, I found it liberating, but then later I found that I
missed the camaraderie and sense of community in the workplace. After
only 11 months at this job, I applied for a desk job and entered the
daily commuting fray once again. I immediately hated it! I hated the
cubicle environment for the first few months, often contemplating
leaving and asking for my old job again. But with patience and advice
to wait it out from good friends, I resigned myself to my job and
decided to see where it would all lead.
My whole first year in my job, I resented being a "cog in the
corporate wheel", as you phrased in your column. I had always reveled
in being the start-up guy (having worked at a number of start-ups),
working in a rapidly-changing environment, and getting things done.
The pace at which the big corporations (with all their
red-tape) move did not suit me, I told myself (I work at an investment
bank). Consequently, I used that as an excuse to slow my own
productivity down. If no one else around here cares, why should I? I
just got by, delivering the bare minimum, complaining about other
people and generally engaging in most of the behaviors disenchanted
corporate citizens seem to engage in.
I had labeled myself as the start-up guy and didn't accept myself as
working at a large corporation. Really giving myself to my corporate
job would mean that I would have to give up my idea (or
label) that working for a startup was way cooler than working at a big
corporation. I realized I could be right about my story and not like
my job or give up my story and throw myself into my job. I chose the
latter.
I wanted to share with you that a big part in my new outlook on work
and even life has come about because of my work with Instantaneous
Transformation, taught by Ariel & Shya Kane. Working with them, I had
a shift: a sudden insight that I mattered and what I do counts. I saw
my cog-ness but it was in a different light. I saw that others relied
on my cog performing well to do their own job successfully. If I got
slow, they got slow. I realized I feed work to other people and if I
don't feed them work, they become disenchanted and bored and complain
about other people's lack of involvement. Soon they would lose their
enthusiasm and become dim and might even look for other employment.
All this became apparent to me in a flash. I caught a glimpse of the
universe and I saw my role in it and that the way I performed that
role was totally my own choice: I could perform it at a snail's pace
or I could perform it brilliantly and to the best of my abilities. I
chose the latter and I continually choose the latter. I feel a renewed
sense of purpose at work and it has become an exciting adventure for
me. I feel that I am making a genuine contribution to the team and to
the firm. I've even gone above and beyond my role by starting my own
initiatives within the firm.
...
To learn more about the Kanes and their amazing work, go to:
Transformation Made Easy
...
I wanted to share with you my own story of how I transitioned from
working at home to enjoying work in the corporate world. I was in
consulting work briefly so I spent a lot of time working from home
and, at first, I found it liberating, but then later I found that I
missed the camaraderie and sense of community in the workplace. After
only 11 months at this job, I applied for a desk job and entered the
daily commuting fray once again. I immediately hated it! I hated the
cubicle environment for the first few months, often contemplating
leaving and asking for my old job again. But with patience and advice
to wait it out from good friends, I resigned myself to my job and
decided to see where it would all lead.
My whole first year in my job, I resented being a "cog in the
corporate wheel", as you phrased in your column. I had always reveled
in being the start-up guy (having worked at a number of start-ups),
working in a rapidly-changing environment, and getting things done.
The pace at which the big corporations (with all their
red-tape) move did not suit me, I told myself (I work at an investment
bank). Consequently, I used that as an excuse to slow my own
productivity down. If no one else around here cares, why should I? I
just got by, delivering the bare minimum, complaining about other
people and generally engaging in most of the behaviors disenchanted
corporate citizens seem to engage in.
I had labeled myself as the start-up guy and didn't accept myself as
working at a large corporation. Really giving myself to my corporate
job would mean that I would have to give up my idea (or
label) that working for a startup was way cooler than working at a big
corporation. I realized I could be right about my story and not like
my job or give up my story and throw myself into my job. I chose the
latter.
I wanted to share with you that a big part in my new outlook on work
and even life has come about because of my work with Instantaneous
Transformation, taught by Ariel & Shya Kane. Working with them, I had
a shift: a sudden insight that I mattered and what I do counts. I saw
my cog-ness but it was in a different light. I saw that others relied
on my cog performing well to do their own job successfully. If I got
slow, they got slow. I realized I feed work to other people and if I
don't feed them work, they become disenchanted and bored and complain
about other people's lack of involvement. Soon they would lose their
enthusiasm and become dim and might even look for other employment.
All this became apparent to me in a flash. I caught a glimpse of the
universe and I saw my role in it and that the way I performed that
role was totally my own choice: I could perform it at a snail's pace
or I could perform it brilliantly and to the best of my abilities. I
chose the latter and I continually choose the latter. I feel a renewed
sense of purpose at work and it has become an exciting adventure for
me. I feel that I am making a genuine contribution to the team and to
the firm. I've even gone above and beyond my role by starting my own
initiatives within the firm.
...
To learn more about the Kanes and their amazing work, go to:
Transformation Made Easy
A Case for Prototyping
As a BA, prototyping is an essential function. In fact, I feel it’s probably the single most important thing to do when gathering requirements from users, yet how often do we engage in it? Fred Brooks, a Turing award winner [equivalent to a Nobel Prize for computer science], writes in his now famous article about software engineering, “No Silver Bullet”, about the importance of prototyping when creating software. See excerpt below.
Requirements refinement and rapid prototyping.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. Even the simple answer--"Make the new software system work like our old manual information-processing system" --is in fact too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.
Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.
A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptional tasks, respond correctly to invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.
Often times, UAT [User Acceptance Testing] is the first time the user gets a chance to look at the system. And this is way too late in the game to change things (although it is often done anyway). In one project I heard about, the lead BA hadn’t seen a working screen until a month before deployment of the software, after an initial 8 month development cycle!
BAs do use prototyping tools such as PowerPoint and Visio to create screenshots for their users. In some cases, groups may be fortunate to have an Information Architect (IA) on their team who is well-versed in using Adobe Photoshop, or InDesign to quickly do mock-ups and wireframes. This is a great thing to do because it gives the end-user the ability to visualize what s/he will be seeing. However, (1) end-users may glance at a screenshot and just nod and say OK without really digesting it and (2) screenshots still fall short in that behavior of the application is not described or experienced.
Prototyping is the next best thing to having a real application on one’s desktop. A simulation of the software or a raw version of the actual to-be-delivered software makes the user experience much richer and elicits more accurate feedback than any static screenshot can. Prototypes with use cases or scripts are a very powerful combination to drive a focused requirements gathering exercise.
A few prototyping tools that simulate behavior are out in the market already. Mockupscreens (from Mockupscreens.com), iRise (iRise.com) and Axure (axure.com) are three tools that seem to be popular. Indeed, I have used Axure to create a working html prototype (6 webpages) of a car website in 45 minutes.
Furthermore, in many projects currently, software cycles are planned so that the front-end, back-end and middle-tiers are developed and arrive at the same time, all to be released to the end-user. My argument is that we go ahead and concentrate on building the front-end first as a prototype, and deploy it to specific end-users and stakeholders with the intention of eliciting feedback. Clicking on buttons and menus will bring up windows and pop-ups with tables of dummy data that can be prepared beforehand by the BA. This will give as close an approximation to what the end-user will see in UAT but much earlier on in the process. BAs can correct requirements and obtain new ones as the end users ‘demo’ the software.
In each iteration of the cycle, working software is always in place and a constant flow of new functionality is added as the software grows. Again as Brooks says:
The system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below… I have seen most dramatic results since I began urging this technique [Incremental Development] on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness…The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system.
The end users will also get excited as the system takes on the look and feel they desire. Constant back and forth between IT and the business occurs and a positive feedback loop emerges. Collaboration becomes the new name of the game. As IT tweaks the prototype to align with what the business wants, the end users see that IT is responsive to their needs immediately and a collaborative spirit ensues.
One hazard with this method is that end users may be too eager for the system once they see it (even if it’s only a prototype) but these expectations can be managed. The focus should be on building a collaboration; a business user who is much more engaged and eager to deal with IT is far more preferable to one who sits back and has to wait until UAT to finally see a working system that may or may not fill their needs.
Requirements refinement and rapid prototyping.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. Even the simple answer--"Make the new software system work like our old manual information-processing system" --is in fact too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.
Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.
A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptional tasks, respond correctly to invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.
Often times, UAT [User Acceptance Testing] is the first time the user gets a chance to look at the system. And this is way too late in the game to change things (although it is often done anyway). In one project I heard about, the lead BA hadn’t seen a working screen until a month before deployment of the software, after an initial 8 month development cycle!
BAs do use prototyping tools such as PowerPoint and Visio to create screenshots for their users. In some cases, groups may be fortunate to have an Information Architect (IA) on their team who is well-versed in using Adobe Photoshop, or InDesign to quickly do mock-ups and wireframes. This is a great thing to do because it gives the end-user the ability to visualize what s/he will be seeing. However, (1) end-users may glance at a screenshot and just nod and say OK without really digesting it and (2) screenshots still fall short in that behavior of the application is not described or experienced.
Prototyping is the next best thing to having a real application on one’s desktop. A simulation of the software or a raw version of the actual to-be-delivered software makes the user experience much richer and elicits more accurate feedback than any static screenshot can. Prototypes with use cases or scripts are a very powerful combination to drive a focused requirements gathering exercise.
A few prototyping tools that simulate behavior are out in the market already. Mockupscreens (from Mockupscreens.com), iRise (iRise.com) and Axure (axure.com) are three tools that seem to be popular. Indeed, I have used Axure to create a working html prototype (6 webpages) of a car website in 45 minutes.
Furthermore, in many projects currently, software cycles are planned so that the front-end, back-end and middle-tiers are developed and arrive at the same time, all to be released to the end-user. My argument is that we go ahead and concentrate on building the front-end first as a prototype, and deploy it to specific end-users and stakeholders with the intention of eliciting feedback. Clicking on buttons and menus will bring up windows and pop-ups with tables of dummy data that can be prepared beforehand by the BA. This will give as close an approximation to what the end-user will see in UAT but much earlier on in the process. BAs can correct requirements and obtain new ones as the end users ‘demo’ the software.
In each iteration of the cycle, working software is always in place and a constant flow of new functionality is added as the software grows. Again as Brooks says:
The system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below… I have seen most dramatic results since I began urging this technique [Incremental Development] on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness…The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system.
The end users will also get excited as the system takes on the look and feel they desire. Constant back and forth between IT and the business occurs and a positive feedback loop emerges. Collaboration becomes the new name of the game. As IT tweaks the prototype to align with what the business wants, the end users see that IT is responsive to their needs immediately and a collaborative spirit ensues.
One hazard with this method is that end users may be too eager for the system once they see it (even if it’s only a prototype) but these expectations can be managed. The focus should be on building a collaboration; a business user who is much more engaged and eager to deal with IT is far more preferable to one who sits back and has to wait until UAT to finally see a working system that may or may not fill their needs.
A great story in the WSJ
This is an example of phenomenal customer service and of going above and beyond for customers!
From the Wall St. Journal, 08/28/2007:
To a United Pilot, The Friendly Skies Are a Point of Pride Capt. Flanagan Goes to Bat For His Harried Passengers; August 28, 2007; Page A1
Capt. Denny Flanagan is a rare bird in today's frustration-filled air-travel world -- a pilot who goes out of his way to make flying fun for passengers.
When pets travel in cargo compartments, the United Airlines veteran snaps pictures of them with his cellphone camera, then shows owners that their animals are on board. In the air, he has flight attendants raffle off 10% discount coupons and unopened bottles of wine. He writes notes to first-class passengers and elite-level frequent fliers on the back of his business cards, addressing them by name and thanking them for their business. If flights are delayed or diverted to other cities because of storms, Capt. Flanagan tries to find a McDonald's where he can order 200 hamburgers, or a snack shop that has apples or bananas he can hand out.
And when unaccompanied children are on his flights, he personally calls parents with reassuring updates. "I picked up the phone and he said, 'This is the captain from your son's flight,' " said Kenneth Klein, whose 12-year-old son was delayed by thunderstorms in Chicago last month on a trip from Los Angeles to see his grandfather in Toronto. "It was unbelievable.
One of the big problems is kids sit on planes and no one tells you what's happening, and this was the exact opposite."
So unusual is the service that Capt. Flanagan has been a subject of discussion on FlyerTalk.com1, an online community for road warriors.
Mark B. Lasser, a Denver advertising-sales executive, came off a Capt.
Flanagan flight and posted a question on FlyerTalk.com about why the pilot had been so friendly. "I don't trust UA at all but can't figure out what the ulterior motive is," he wrote.
Others quickly came to Capt. Flanagan's defense. "I've had this pilot before
-- what a great guy. He does the same thing on every flight," said a FlyerTalk regular.
Mr. Lasser says he just wishes Capt. Flanagan weren't such a rarity among United employees. "Every flight before and most flights since have been so poor in customer service that this guy really came across as representing his own standards more than the company's. He's an outlier within United,"
Mr. Lasser said in an interview.
UAL Corp.'s United, which ranked in the middle of the airline pack in on-time arrivals and mishandled baggage in the first half of this year and next-to-worst in consumer complaints, has supported Capt. Flanagan's efforts. The airline supplies the airplane trading-cards he hands out as passengers board, plus books, wine and discount coupons he has flight attendants give away. He goes through about 700 business cards a month, and the company reimburses him for the food he buys during prolonged delays.
"He's a great ambassador for the company," says Graham Atkinson, United's executive vice president and "Chief Customer Officer," who is leading an effort to boost customer service. He hopes more pilots and airport workers will adopt some of Capt. Flanagan's techniques such as the frequent, detailed updates he gives to customers.
Air travel isn't easy for anybody, given problems ranging from storms to mechanical breakdowns to computer snafus and lost luggage. Airline workers have endured pay cuts and fights with management; travelers have suffered poor service and unreliable flights. Capt. Flanagan tries to deal with the cheerfulness challenge -- at least on the flights he works. "I just treat everyone like it's the first flight they've ever flown," said the 56-year-old Navy veteran who lives on an Ohio farm and cuts the figure of a classic airline captain: trim and gray-haired. "The customer deserves a good travel experience," he said.
Last Tuesday morning, Capt. Flanagan was at gate C19 at Chicago's O'Hare International Airport an hour before the scheduled departure of Flight 831 to San Francisco and made his first announcement about the delay before the gate agent had shown up. The time posted for departure was 8:20, but that was optimistic, Capt. Flanagan told passengers, because the Boeing 767 they would fly wouldn't land from São Paulo, Brazil, until 7:02 and then had to be emptied, cleaned, inspected and towed from the international terminal.
He tried to lighten the mood, using a joke he tells before every flight. "I almost forgot to tell you, this is my first flight," Capt. Flanagan said.
Wary eyes looked up from newspapers and BlackBerrys through a long pause, before he added, "today."
Capt. Flanagan mingled in the lounge answering questions and using his cellphone to call United operations officials to ask about connections to Asia and to cities on the West Coast.
Ajoke Odumosu, a track star at the University of South Alabama who was on her way to Osaka, Japan, for a world-championship competition, realized that when she began her trip with US Airways Group Inc., her luggage had been checked only as far as San Francisco. With the delay, there wouldn't be time to retrieve it and recheck it for Japan.
Capt. Flanagan called Chicago and learned that the luggage was already in metal containers ready for loading on the 767, and couldn't be retagged. He called San Francisco and found a manager who agreed to pull Ms. Odumosu's bags aside and retag them for Osaka. In all, he spent 15 minutes on the problem.
"I was glad he went out of his way, which he didn't have to do," Ms. Odumosu said.
Once the plane was ready for boarding, Capt. Flanagan passed out cards with information about the Boeing 767. On every flight, he signs two of the cards on the back and, if there is wine left over from first class, he announces that passengers with his signature have won bottles of wine.
When the movie ended, flight attendants passed out napkins and passengers were invited to write notes about experiences on United -- good or bad.
Fifteen were selected to receive a coupon for a 10% discount on a future United flight, and Capt. Flanagan posts the passengers' notes in crew rooms or sends them on to airport managers when they raise specific issues.
Randall Levelle of Morgantown, W.Va., and his family were flying to San Francisco because his father-in-law had just died. Capt. Flanagan invited Mr. Levelle's three children into the cockpit during boarding.
"If other folks in the airline industry had the same attitude, it would go a long way to mitigating some of the negative stuff that has come about in the last four or five years," Mr. Levelle said.
From the Wall St. Journal, 08/28/2007:
To a United Pilot, The Friendly Skies Are a Point of Pride Capt. Flanagan Goes to Bat For His Harried Passengers; August 28, 2007; Page A1
Capt. Denny Flanagan is a rare bird in today's frustration-filled air-travel world -- a pilot who goes out of his way to make flying fun for passengers.
When pets travel in cargo compartments, the United Airlines veteran snaps pictures of them with his cellphone camera, then shows owners that their animals are on board. In the air, he has flight attendants raffle off 10% discount coupons and unopened bottles of wine. He writes notes to first-class passengers and elite-level frequent fliers on the back of his business cards, addressing them by name and thanking them for their business. If flights are delayed or diverted to other cities because of storms, Capt. Flanagan tries to find a McDonald's where he can order 200 hamburgers, or a snack shop that has apples or bananas he can hand out.
And when unaccompanied children are on his flights, he personally calls parents with reassuring updates. "I picked up the phone and he said, 'This is the captain from your son's flight,' " said Kenneth Klein, whose 12-year-old son was delayed by thunderstorms in Chicago last month on a trip from Los Angeles to see his grandfather in Toronto. "It was unbelievable.
One of the big problems is kids sit on planes and no one tells you what's happening, and this was the exact opposite."
So unusual is the service that Capt. Flanagan has been a subject of discussion on FlyerTalk.com1, an online community for road warriors.
Mark B. Lasser, a Denver advertising-sales executive, came off a Capt.
Flanagan flight and posted a question on FlyerTalk.com about why the pilot had been so friendly. "I don't trust UA at all but can't figure out what the ulterior motive is," he wrote.
Others quickly came to Capt. Flanagan's defense. "I've had this pilot before
-- what a great guy. He does the same thing on every flight," said a FlyerTalk regular.
Mr. Lasser says he just wishes Capt. Flanagan weren't such a rarity among United employees. "Every flight before and most flights since have been so poor in customer service that this guy really came across as representing his own standards more than the company's. He's an outlier within United,"
Mr. Lasser said in an interview.
UAL Corp.'s United, which ranked in the middle of the airline pack in on-time arrivals and mishandled baggage in the first half of this year and next-to-worst in consumer complaints, has supported Capt. Flanagan's efforts. The airline supplies the airplane trading-cards he hands out as passengers board, plus books, wine and discount coupons he has flight attendants give away. He goes through about 700 business cards a month, and the company reimburses him for the food he buys during prolonged delays.
"He's a great ambassador for the company," says Graham Atkinson, United's executive vice president and "Chief Customer Officer," who is leading an effort to boost customer service. He hopes more pilots and airport workers will adopt some of Capt. Flanagan's techniques such as the frequent, detailed updates he gives to customers.
Air travel isn't easy for anybody, given problems ranging from storms to mechanical breakdowns to computer snafus and lost luggage. Airline workers have endured pay cuts and fights with management; travelers have suffered poor service and unreliable flights. Capt. Flanagan tries to deal with the cheerfulness challenge -- at least on the flights he works. "I just treat everyone like it's the first flight they've ever flown," said the 56-year-old Navy veteran who lives on an Ohio farm and cuts the figure of a classic airline captain: trim and gray-haired. "The customer deserves a good travel experience," he said.
Last Tuesday morning, Capt. Flanagan was at gate C19 at Chicago's O'Hare International Airport an hour before the scheduled departure of Flight 831 to San Francisco and made his first announcement about the delay before the gate agent had shown up. The time posted for departure was 8:20, but that was optimistic, Capt. Flanagan told passengers, because the Boeing 767 they would fly wouldn't land from São Paulo, Brazil, until 7:02 and then had to be emptied, cleaned, inspected and towed from the international terminal.
He tried to lighten the mood, using a joke he tells before every flight. "I almost forgot to tell you, this is my first flight," Capt. Flanagan said.
Wary eyes looked up from newspapers and BlackBerrys through a long pause, before he added, "today."
Capt. Flanagan mingled in the lounge answering questions and using his cellphone to call United operations officials to ask about connections to Asia and to cities on the West Coast.
Ajoke Odumosu, a track star at the University of South Alabama who was on her way to Osaka, Japan, for a world-championship competition, realized that when she began her trip with US Airways Group Inc., her luggage had been checked only as far as San Francisco. With the delay, there wouldn't be time to retrieve it and recheck it for Japan.
Capt. Flanagan called Chicago and learned that the luggage was already in metal containers ready for loading on the 767, and couldn't be retagged. He called San Francisco and found a manager who agreed to pull Ms. Odumosu's bags aside and retag them for Osaka. In all, he spent 15 minutes on the problem.
"I was glad he went out of his way, which he didn't have to do," Ms. Odumosu said.
Once the plane was ready for boarding, Capt. Flanagan passed out cards with information about the Boeing 767. On every flight, he signs two of the cards on the back and, if there is wine left over from first class, he announces that passengers with his signature have won bottles of wine.
When the movie ended, flight attendants passed out napkins and passengers were invited to write notes about experiences on United -- good or bad.
Fifteen were selected to receive a coupon for a 10% discount on a future United flight, and Capt. Flanagan posts the passengers' notes in crew rooms or sends them on to airport managers when they raise specific issues.
Randall Levelle of Morgantown, W.Va., and his family were flying to San Francisco because his father-in-law had just died. Capt. Flanagan invited Mr. Levelle's three children into the cockpit during boarding.
"If other folks in the airline industry had the same attitude, it would go a long way to mitigating some of the negative stuff that has come about in the last four or five years," Mr. Levelle said.
Sunday, September 2, 2007
Customer Service!
This blog is about Business Best Practices and specifically about Business Analysis which is what I do for a living, but I expect to cover all kinds of topics that come up.
Let's get down to it, shall we?
Here's a draft of an article i want to write for a newsletter I'm putting together.
Customer Service
Most jobs can be thought of as customer-service oriented. We have deadlines and projects we need to meet and complete but many of us forget that these things are constructed by people.
And then we're given another task on top of what we have, and we holler, we complain (internally much of the time). we'll never get through it, we exclaim.
I think Tom Peters may have talked about this when he speaks of "A Brand of You." Treat yourself like your own corporation. Have excellent customer service. Treat your fellow co-workers as your clients.
"What's the best way to get something done? Give it to the busy person." If you're busy, chances are you're doing something right; You know how to get things done which bodes well for your career, wherever you go. But consider Customer Service: Many of us don't interact with the end-customer or client in our day-to-day jobs but it is possible to re-frame our jobs in a new way: We can consider ourselves a one-person corporation and consider everyone we interact with on the job a client of ours. Everyone knows that customer service and keeping customers happy is one of the primary aims of a company so with that picture in mind, how would you behave differently?
Picture this: You are juggling multiple tasks in order to get projects done. However, you're roadblocked on a few items because someone you've reached out to hasn't gotten back to you. One day goes by, two days, ... one week and so on.
Has this happened to you? We tend to think that when people don't respond to us, that no one but us cares. After awhile, we become disenchanted and slow and complain about beauracracy and large corporations. But pause for a second and take a look at how you operate. Are there tasks, phone calls, e-mail from people who are waiting on you to get back to them? I've found it uncanny how when I clear up my own queue of tasks in which I need to get back to someone (whether it's professional or personal) that something (or someone) I've been waiting on clears up all on its own and I can proceed with my 'real work'.
Also from a customer service point of view, just think that the time you take to help someone with their task will free them up to continue doing their job and for you to move on with yours. You've provided good customer service. This has the added benefit of good-will and enhancing relationships. It might mean taking a breath and biting your tongue and re-focusing; but putting your attention on the present moment and whatever the 'interruption' is can be a very positive thing. It also contributes to an improved perception of you by others. People will perceive you as crisp, on top of things, and attentive, all important and desirable characteristics for any employee. When you go out of your way for someone, it leaves a lasting impression.
This can be extended to beyond returning voicemail and e-mail. How about those tasks you've been putting off for the longest time? Getting to those "non-preferred" tasks will clear up the air, give you a sense of accomplishment and amazingly (in my own experience) open up other doors as soon as you're done with that other task. I call them 'just-in-time opportunities'.
We all know that relationships are one of the primary keys to having a successful work life and for getting things done. People you have good relationships with will continue to help you out and help you move forward in your career.
Organizational and Time Management
Let's get down to it, shall we?
Here's a draft of an article i want to write for a newsletter I'm putting together.
Customer Service
Most jobs can be thought of as customer-service oriented. We have deadlines and projects we need to meet and complete but many of us forget that these things are constructed by people.
And then we're given another task on top of what we have, and we holler, we complain (internally much of the time). we'll never get through it, we exclaim.
I think Tom Peters may have talked about this when he speaks of "A Brand of You." Treat yourself like your own corporation. Have excellent customer service. Treat your fellow co-workers as your clients.
"What's the best way to get something done? Give it to the busy person." If you're busy, chances are you're doing something right; You know how to get things done which bodes well for your career, wherever you go. But consider Customer Service: Many of us don't interact with the end-customer or client in our day-to-day jobs but it is possible to re-frame our jobs in a new way: We can consider ourselves a one-person corporation and consider everyone we interact with on the job a client of ours. Everyone knows that customer service and keeping customers happy is one of the primary aims of a company so with that picture in mind, how would you behave differently?
Picture this: You are juggling multiple tasks in order to get projects done. However, you're roadblocked on a few items because someone you've reached out to hasn't gotten back to you. One day goes by, two days, ... one week and so on.
Has this happened to you? We tend to think that when people don't respond to us, that no one but us cares. After awhile, we become disenchanted and slow and complain about beauracracy and large corporations. But pause for a second and take a look at how you operate. Are there tasks, phone calls, e-mail from people who are waiting on you to get back to them? I've found it uncanny how when I clear up my own queue of tasks in which I need to get back to someone (whether it's professional or personal) that something (or someone) I've been waiting on clears up all on its own and I can proceed with my 'real work'.
Also from a customer service point of view, just think that the time you take to help someone with their task will free them up to continue doing their job and for you to move on with yours. You've provided good customer service. This has the added benefit of good-will and enhancing relationships. It might mean taking a breath and biting your tongue and re-focusing; but putting your attention on the present moment and whatever the 'interruption' is can be a very positive thing. It also contributes to an improved perception of you by others. People will perceive you as crisp, on top of things, and attentive, all important and desirable characteristics for any employee. When you go out of your way for someone, it leaves a lasting impression.
This can be extended to beyond returning voicemail and e-mail. How about those tasks you've been putting off for the longest time? Getting to those "non-preferred" tasks will clear up the air, give you a sense of accomplishment and amazingly (in my own experience) open up other doors as soon as you're done with that other task. I call them 'just-in-time opportunities'.
We all know that relationships are one of the primary keys to having a successful work life and for getting things done. People you have good relationships with will continue to help you out and help you move forward in your career.
Organizational and Time Management
Subscribe to:
Posts (Atom)