Posts categorized "Continuous Improvement"

November 27, 2007

The good kind of failure

“I have not failed. I have just found ten thousand ways that won’t work.”
                                                                                    - Thomas Edison

Resiliency and learning from your "mistakes" are critical to building a successful venture. 

Organizing your efforts to avoid "mistakes" and to have no risk of "failure" is a bad strategy.  Organizing your efforts to "fail faster" so that you can learn from your mistakes and course correct as you go is a good strategy.

It is important to distinguish between making new mistakes which are the good kind that you learn from; and simply repeating the same mistakes that have been made before and should now be avoidable.

                                                                               copyright 2007 Kerry Champion

November 26, 2007

You can't improve without change

Different Isn't Always Better, But Better's Always Different
                                                      - 
Jonathan Schwartz

June 05, 2007

Surveillance and diligence

As I mentioned in a previous post I recently heard Atul Gawande talk about his book "BETTER: A Surgeon’s Notes on Performance".  He made observations about why some teams have much better results (in terms of patient medical outcomes) than others.

He highlighted two traits that seemed to be central to that success: "surveillance" and "diligence".  These traits are incredibly important in the software world as well, for much the same reasons as touched on by Atul.

I am not sure that "surveillance" is the best possible phrase to use, I prefer to think in terms of "active observation."  Whatever the label the concept is critical.  Here are some points to keep in mind when practicing active observation:

  • Don't depend solely on your own observations, enlist the broader team to take part in the process and listen carefully when they share what they are seeing.
     
  • Don't accept everything you hear at face value, question and probe, search for validating or contradictory data points.
     
  • Make sure you have a good consistent data set that lets you make comparisons over time and comparisons between different people and different projects.  When there is variation in that data set probe into it, even if the variation seems small.
     
  • Take advantage of your insights into well known patterns of misleading reports.  Some folks are modest and pessimistic and consistently make things sound worse than they are.  Others may tend towards self-justification.  In any case you need to look for these patterns and take them into account as you get new reports from the same source.
     
  • As you form conclusions based on these observations, test that conclusion, make predictions based on that conclusion and go look at the relevant data.  If your new data points don't support your prediction, than your conclusions are probably wrong.

Atul makes some key points regarding "diligence":

  • Diligence can be defined as "the constant and earnest effort to accomplish what is undertaken."
     
  • "People underestimate the importance of diligence as a virtue" perhaps because on the surface it sounds mundane and simplistic.
       
  • However, diligence is a "prerequisite of great accomplishment" and "one of the most difficult challenges facing any group of people who take on tasks of risk and consequence"

I agree wholeheartedly with these points and would add just a couple more regarding the practice of diligence. 

  • It is unreasonable to expect diligence from someone who does not understand why their tasks matter in the bigger scheme of things.
       
  • Having relevant and easy to understand metrics that are shared with the entire team, encourages diligence and continuous improvement.
       
  • Developing team practices that enable folks to get into a good rhythm and spend most of their time "in the zone" is critical to encouraging diligence.  There are lots of things (too many meetings, unproductive meetings, inconsistent goals/feedback, constantly switching assignments, etc.) that will pull folks out of the productive zone and discourage them from trying.
     
  • An out-of-context or irrelevant response to anxiety or social tension is called a displacement behavior.   I believe this term was originally from animal behavior studies, but it certainly applies to humans as well.  For example you may feel anxious about a deadline, doing the relevant work just reminds you of how hard it will be to make the deadline, which makes you even more anxious, so you find yourself reading Slashdot or reorganizing the source tree instead of actually working on the relevant implementation.  Team leaders need to give folks an open door and when they express anxiety or point out tension, leaders need to help them work-around those issues so they can pursue the tasks that matter instead of getting sucked into an eddy.   

Here is Atul's description of a Doctor who has mastered the arts of surveillance and diligence.  This describes an examination of a Cystic Fibrosis patient (Janelle) by her Doctor (Warwick).  Even though the specifics of this situation are far from the specifics of a software project, the mindset and basic skills shown here are extremely relevant.

Warwick pulled out her latest lung-function measurements. There’d been a slight dip, ... Three months earlier, Janelle had been at a hundred and nine per cent (she was actually doing better than normal); now she was at around ninety per cent. Ninety per cent was still pretty good, and some ups and downs in the numbers are to be expected. But this was not the way Warwick saw the results.

He knitted his eyebrows. “Why did they go down?” he asked.

Janelle shrugged.

Any cough lately? No. Colds? No. Fevers? No. Was she sure she’d been taking her treatments regularly? Yes, of course. Every day? Yes. Did she ever miss treatments? Sure. Everyone does once in a while. How often is once in a while?

Then, slowly, Warwick got a different story out of her: in the past few months, it turned out, she’d barely been taking her treatments at all.

He pressed on. “Why aren’t you taking your treatments?” He appeared neither surprised nor angry. He seemed genuinely curious, as if he’d never run across this interesting situation before.

“I don’t know.”

He kept pushing. “What keeps you from doing your treatments?”

“I don’t know.”

“Up here”—he pointed at his own head—“what’s going on?”

I dont know,” she said.

He paused for a moment. And then he began speaking to me, taking a new tack. “The thing about patients with CF is that they’re good scientists,” he said. “They always experiment. We have to help them interpret what they experience as they experiment. So they stop doing their treatments. And what happens? They don’t get sick. Therefore, they conclude, Dr. Warwick is nuts.”

“Let’s look at the numbers,” he said to me, ignoring Janelle. He went to a little blackboard he had on the wall. It appeared to be well used. “A person’s daily risk of getting a bad lung illness with CF is 0.5 per cent.” He wrote the number down. Janelle rolled her eyes. She began tapping her foot. “The daily risk of getting a bad lung illness with CF plus treatment is 0.05 per cent,” he went on, and he wrote that number down. “So when you experiment you’re looking at the difference between a 99.95-per-cent chance of staying well and a 99.5-per-cent chance of staying well. Seems hardly any difference, right? On any given day, you have basically a one-hundred-per-cent chance of being well. But”—he paused and took a step toward me—“it is a big difference.” He chalked out the calculations. “Sum it up over a year, and it is the difference between an eighty-three-per-cent chance of making it through 2004 without getting sick and only a sixteen-per-cent chance.”

He turned to Janelle. “How do you stay well all your life? How do you become a geriatric patient?” he asked her. Her foot finally stopped tapping. “I can’t promise you anything. I can only tell you the odds.”

In this short speech was the core of Warwick’s world view. He believed that excellence came from seeing, on a daily basis, the difference between being 99.5-per-cent successful and being 99.95-per-cent successful. Many activities are like that, of course: catching fly balls, manufacturing microchips, delivering overnight packages. Medicine’s only distinction is that lives are lost in those slim margins.

And so he went to work on finding that margin for Janelle. Eventually, he figured out that she had a new boyfriend. She had a new job, too, and was working nights. The boyfriend had his own apartment, and she was either there or at a friend’s house most of the time, so she rarely made it home to take her treatments. At school, new rules required her to go to the school nurse for each dose of medicine during the day. So she skipped going. “It’s such a pain,” she said. He learned that there were some medicines she took and some she didn’t. One she took because it was the only thing that she felt actually made a difference. She took her vitamins, too. (“Why your vitamins?” “Because they’re cool.”) The rest she ignored.

Warwick proposed a deal. Janelle would go home for a breathing treatment every day after school, and get her best friend to hold her to it. She’d also keep key medications in her bag or her pocket at school and take them on her own. (“The nurse won’t let me.” “Don’t tell her,” he said, and deftly turned taking care of herself into an act of rebellion.) So far, Janelle was O.K. with this. But there was one other thing, he said: she’d have to come to the hospital for a few days of therapy to recover the lost ground. She stared at him.

“Today?”

“Yes, today.”

“How about tomorrow?”

“We’ve failed, Janelle,” he said. “It’s important to acknowledge when we’ve failed.”

With that, she began to cry.

Warwick’s combination of focus, aggressiveness, and inventiveness is what makes him extraordinary. He thinks hard about his patients, he pushes them, and he does not hesitate to improvise.

I particularly appreciate the comment "... combination of focus, aggressiveness, and inventiveness is what makes him extraordinary"  That certainly applies to the software world as well.

                                                                               copyright 2007 Kerry Champion

May 30, 2007

Ineptitude or ignorance

in·ept   \i-ˈnept\
1
: lacking in fitness or aptitude : unfit  <inept at sports>    
2 : lacking sense or reason : foolish        
3
: not suitable to the time, place, or occasion : inappropriate often to an absurd degree <an inept metaphor>        
4
: generally incompetent
ig·no·rant   \ˈig-n(ə-)rənt\
1
: destitute of knowledge or education <an ignorant society>
2
: lacking knowledge or comprehension of the thing specified <parents ignorant of modern mathematics>  
3 : generally unaware,   uninformed

I recently heard Atul Gawande talk at Kepler's.  He has written "BETTER: A Surgeon’s Notes on Performance".  The issues of how to achieve peak performance, how to achieve optimal outcomes, was central to his talk.  Some of the lessons he discussed seem very applicable to  the software world.

For example one phrase that caught my attention was the question of "ignorance vs. ineptitude".

He makes the case that the fundamental barrier to optimal outcomes changed during the last century.  In the 19th century the real issue was ignorance.  Understanding the germ theory, understanding the mechanisms of metabolism, understanding genetics, etc. etc. were the most important challenges to improving real world medical care.  In other words the issue was ignorance.

In the 21st century the situation is fundamentally different.  There is still plenty to learn, it is not the case that ignorance is banished.  However, now the biggest near term opportunity for improved performance is addressing issues of ineptitude, rather than ignorance.  The most immediate "bang for the buck" comes from addressing issues where the knowledge required is present but the problem is effectively applying that knowledge.  The barriers in these cases are diverse: organizational, social, economic, and emotional.  Issues that fall into this category include:

  • Creating drug resistant microbes through misuse of antibiotics.  (We will see more of these types of scares as a result.)
  • Failure to maximize longevity of cystic fibrosis and diabetes patients through failures in "disease management" practices. 
  • In-hospital medical mistakes, such as giving out the wrong drug dosage (one study suggests more die of medical mistakes in hospitals than from car accidents).
  • Ineffective practices to encourage consistent pill taking regimes.  (I know this sounds trivial but it is a significant source of bad outcomes.)
  • etc. etc.

All of these issues can be addressed today without any medical breakthrough required.  What is required is:

  • Understanding of human nature and what it is in human nature that gets in the way of applying what we know.
  • Having the will, focus, and discipline required to act and to not stop till you have achieved improved results.

I believe similar points can be made about software development.  Way too many software teams consistently operate far below peak performance, way too many software projects have far from optimal outcomes, and the biggest barrier is ineptitude, not ignorance.  Too often there are perverse incentives, or emotional reactions or consistent behavioral issues that stop us applying lessons we have already learned.  Which in turn leads to us make the same mistakes over and over again.

                                                                               copyright 2007 Kerry Champion

Unexamined life is not worth living

"An unexamined life is not worth living."
                  --  Socrates

This is obviously not literally so, yet there is some fundamental truth here.

There is no question that every human activity benefits from thoughtful observation and reflection.  More specifically, for activities where we are consciously trying to achieve peak performance and continuous improvement, such observation and reflection is an absolute requirement. 

Software ventures clearly fall in this latter category.  A mature and evolved organization will proactively work against an agenda that is driven by thoughtful self-observation.  If you find that is not the case, if you find that you are constantly focused on reacting and firefighting, if you are always responding to the urgent and never working on the important, than I recommend you  remember old Socrates: step back and examine your work life.

                                                                               copyright 2007 Kerry Champion


May 06, 2007

What does a teaching hospital have to teach a software team?

Stanford Hospital is one of the better known institutions in Silicon Valley.  It is a  teaching hospital where some of the best learn their profession.  Every day the doctors and staff take the time to share what they know and improve their skills.  They do this through a variety of mechanisms: doing rounds together, meeting to review patient outcomes, reviewing charts and asking questions, writing papers, presenting at conferences, etc.  They do all this while literally dealing with life and death issues, and while working inhumanly long hours.

Often in software teams you will hear comments such as these:

  • I don't have time to train the new guy, just have him read the code.
  • It is too much hassle to include a comment explaining my checkin.
  • There is not enough time to talk the whole team through the architecture of the new module and explain why we made the decisions we made.
  • We just can't seem to fit in the code reviews.
  • Oh I never bother filling in the "root cause" field when closing a bug in the bug base, no one is interested.
  • What is the point of doing a debriefing now that the release is over, no one will pay attention to the results.
  • etc. etc.

Sometimes my response is:  "Staff at teaching hospitals work long hours under intense stress.  Just down the road at Stanford they still find time to fill in charts, go on rounds, go to postmortems, and all the rest.  If they can both 'do and teach' why can't we?"

One of the things that makes teaching hospitals so effective is they don't just teach from books (medical school takes care of that) they teach through considered examination of real life situations.  Software teams have the opportunity to do the same thing.

Teaching a rapidly evolving body of knowledge, requires observation, reflection and articulation.  Software teams are often very bad at all three, rushing from the latest new feature to fixing the customer critical bug, without taking the time to gather observations, reflect on that data drawing useful conclusions, and then capture those insights into a form that can be transmitted again and again.

To make your team the equivalent of a teaching hospital, to make it a "teaching team", requires several elements:

  • Management must buy in to the idea that investing in these practices now will pay off with greater total throughput over time. Then team leaders must go on to implement the specific practices: code reviews, bug analysis, project debriefings, etc.
     
  • Team members must organize their own work and adapt their attitudes to avoid creating a culture where the "urgent" gets all attention and the "important" gets ignored.
     
  • Everyone must constantly ask themselves "ok we have solved this immediate problem, what lesson should we learn from it and how should we spread that lesson around?"

Failure to make a "teaching team" is one of the key leading indicators that you are bound to repeat the same mistakes over and over.

                                                                               copyright 2007 Kerry Champion

 

April 26, 2007

Don't just test, change how you code

When deciding on your testing plans and your process for handling bugs, keep in mind this question:

Which practices will go beyond reporting a snapshot of current quality?  Which practices will drive positive changes in how we develop going forward?

One unfortunate pattern you see in many software teams is:

  1. Have a set of programmers who are responsible for making new functionality appear as quickly as possible.
  2. Have a set of testers who are responsible for quality.
  3. Have the programmers "hand off" new features to testers as soon as possible, so they can move on to the next new feature they need to implement.
  4. Don't have testers interact with programmers (review design, do preliminary testing, create/review test plans) until the feature is 'done', and even then have minimal interaction.
  5. Have the primary communication between testers and programmers be the bug database.  The only real 'output' of the testers is to create bugs in the bug database.
  6. A manager will prioritize the entries in the bug database and an engineer will be assigned to resolve each high priority bug.
  7. Metrics are kept for inflow, outflow, total bug counts for each priority level.  But other than that no analysis is done to look for patterns in the bugs.  Does a bug represent one of a common type? Are parts of the codebase much more prone to having bugs reported against them?  Typically those questions are not answered.
  8. If there is a concern that the quality is not high enough, the reaction is to increase the number of testers and the volume of testing.

This approach is far from optimal, of the various issues here are three that stand out:

  • 'responsibility' for quality should be on everyone not just on the testers who measure it.
       
  • this process reinforces a "reactive" approach where the team is driven by what is "urgent" (handing off the current feature, responding to the bug report) rather than what is "important" (improving your skills and practices to increase the baseline productivity and quality of the team going forward).
       
  • this process has no feedback loop that drives the team to improved results

I do believe in having dedicated testers and I do believe in the importance of a bug database and I do believe in tracking bug counts.  However, those things by themselves aren't enough.  You need to go beyond these things to implement QA practices that drive continuous improvement in how you develop, and not just improvement in how you test.

What specific practices make sense depend on your circumstances: size of team, maturity of developers, nature of software being developed, etc.  Here are some possibilities to consider:

  • Require automated unit test to be delivered by the developer before new code is considered 'done' and ready for integration. This does not just result in a useful test, it makes developers think harder about their implementation decision and about how their code may be used.
     
  • To identify potential side-effects require a critical sub-set of all automated tests (not just the ones for the new functionality) to be run as part of the check-in process.  Require that check-ins be held until these tests pass.  This does not just result in fewer broken builds, it encourages developers to think about cross module dependencies.
     
  • Require that the entire universe of automated tests be run as part of daily (or more frequent) build.  If any test fails have the engineers who checked-in during that window stop their work and fix the build before continuing.  This practice reinforces the message that it is more productive to fix bugs in existing code first, before adding new code.
     
  • Measure code coverage generated by automated tests on a daily basis.  Have specific numerical goals for target code coverage.  Have developers (not testers) be the ones responsible for achieving those goals.  This does not just ensure that you have a robust test suite, it also pushes developers to go back and remove redundant code and to simplify the code that they keep.  Both those steps in turn make the code easier to understand and to maintain.
     
  • For bugs found after the developer believes the code is done, in the bug database track the nature and resolution of those bugs.  What part of the codebase was it in?  Was it a logic error, a syntax error, a misunderstanding of the language runtime behavior, a misunderstanding of some public interface, a misunderstanding of requirements, a performance deoptimization, etc?  Look for patterns in this info, share it with the team as a whole and see what conclusions can be drawn.
     
  • For each bug in the bug database that was found through testing, ask the developer who resolves it "is it likely that there are similar undiscovered bugs in the codebase that could be found via inspection/search/analysis?"  If yes, make a specific trackable work item to do that inspection/search/analysis.
     
  • For a sub-set of the bugs in the bug database have the relevant engineer go in front of the team and present the "lesson learned" from that bug.  Such presentations may be short (5-10 minutes, 1-3 slides) and tagged on to some other meeting that is occurring anyway. A steady stream of such presentations (3-6 a week) is best.
     
  • For each non-trivial check-in have the developer write 1-5 bullets that answer "what is the most likely problem to be triggered by this change?" and 1-5 bullets on "suggested system testing to exercise this code."   These bullets can be very terse, it is ok if someone who wants to take action based on one of these bullets has to go back and ask the developer some questions.  However, even the tersest comments, made at the moment that that code is freshly in mind, can be incredibly helpful.
       
  • Have developers take part in system testing.  It would be a mistake to have every developer take part in every system test.  However, it is also a mistake for developers to never help exercise the system as a whole.  They need to understand in a tangible way the system as a whole and not just their piece.  Also having a sense of the challenges facing the testers will drive them to pay more attention to the quality of their code and to do a better job of communicating with the testers.

There are some common threads in the above practices.  One thread is to get developers to foresee where bugs are going to be and resolve them before that bug is found by testing.  Another thread is to move away from "whip it out and hand it off" approach and have practices that encourage developers to review their code multiple times from multiples perspectives.

                                                                                 copyright 2007 Kerry Champion



March 07, 2007

Innovation Via Simplification

Innovations can be categorized into all kinds of different buckets:

  • technical implementation innovations
  • business model innovations
  • process innovations
  • "brave new world" innovations
  • "faster, cheaper, better" innovations
  • etc. etc.

I dearly love "simplifying innovations", that's my favorite category.

To create value through innovation you don't have to add a new feature or create a new service.  Through insight and experimentation you can add just as much value by simplifying.  Discovering how to allow the user to achieve their goals via:

  • a cleaner more intuitive UI
  • a more efficient production process
  • a shorter cycle time in the search/purchase cycle
  • an implementation that may be missing a few bells and whistles but is more compact, higher performance, less error prone
  • etc. etc.

Google and Linux are both good examples of innovation through simplification.

Google's original value prop (things have changed over time) had three cornerstones:

  1. more accurate search results
  2. faster return of those results
  3. a clean and simple home page

Of those three it was the "clean and simple home page" that was the most obvious differentiation to the typical user.   Yahoo and every other "Web Portal" seemed to be competing by seeing how many options, how many features, how much links, and how much text they could cram onto their home page.  Google appeared stunningly different by taking the exact opposite approach, simplifying the UI and focusing on doing one thing (search) extraordinarily well.  That innovation via simplification is what got them launched on the road to success.  The fact they may be drifting from that now does not change the value of the lesson.

Linux is a similar story.  The original Linux implementation clearly had less functionality and fewer device drivers than Windows and the existing UNIX implementations.  The innovations people valued (that made up for what Linux lacked) where all things that simplified the process and the product:

  1. Open source development model. 
    Made it simpler to fix it yourself or buy support/modifications from any of a hundred different vendors
  2. Download for free distribution model.
    Vastly simplified the purchase and license enforcement process.
  3. A design ethic that stressed smaller/faster/fully-reviewed
    Resulted in software that was more reliable, less buggy, more secure, more likely to run on low-end hardware, and delivered better performance on uniprocessors.

The best cultures are the ones that measure success by how simple and obvious the final design is, rather than by how elaborate and baroque it is.  This is true whether you are designing a software product, or a marketing campaign, or a customer support policy.

Often innovation via simplification takes a certain kind of bravery.  You must trust your judgment about what is the right trade-off and not fall into the trap of "lets give them one of everything, because we can't decide what really matters."  This is exactly the kind of bravery and judgment that is required to make a great product.

Learning how to effectively hear the customer is an important step in this process.  As is learning how to avoid too many product commitments too early in the process.

Principled Innovation has a good post on Radical Simplicity, that is worth looking at.  I will leave you with one quote from that post:

“Simplicity is the ultimate sophistication.” (Leonardo da Vinci)


                                                                                 copyright 2007 Kerry Champion

February 18, 2007

Never Your Code Alone

Giles Bowkett added a fresh perspective on the Software as Legos Meme yesterday.  One of his points is that you should not assume too quickly that you have to create a new building block from scratch, but you should first look harder at what you already have.

This thinking about building blocks reminds me of an important observation that is often overlooked.

When studying how software engineers actually spend their time it is a truism that they spend only a  minority of their time designing specific algorithms, defining specific data structures and writing fresh code. 

So where does the rest of the time go?  Well there are several ways to slice it. 

It is often pointed out that more time is spent on maintenance and evolution than on greenfield creation.  That is certainly true.

It is also pointed out that more design time is spent on refining requirements than on actual internals design.  That is also true.

However, in this posting I am interested in another point.  Less often noted is the fact that they typical developer needs to spend more time dealing with the interfaces he interacts with than he does dealing with the core code he authors.  Recognizing that this is true, encourages developers to make targeted investments up front that will save them time and improve quality in the end.

By "interfaces" I mean all interfaces: system interfaces (OS functionality, UI toolkits), major application components (databases, user directories, security libraries), shared data structures, and the internal interfaces to other components under development.  Most engineers tend to underweight the importance of having a truly complete understanding of the interfaces they are using, blithely assuming the actual behavior will be obvious from the declared interface and they will just figure it out as they go along.  This leads to: expensive to fix bugs discovered late in the process, a tendency to rebuild functionality that already exists in another module, and a tendency to constrain user functionality because you are not getting full leverage from the interfaces that are available.

When assigned a new module a responsible developer will go through and read all the code in that module and make sure he understands the code he will be modifying.  He will then go on and write (or extend) some unit tests that demonstrate he really understands that code.  However, he typically does not invest comparable effort to understand the interfaces his code is using.  It is worthwhile to take some steps up front: carefully reading the interfaces, understanding the implementation behind those interfaces, and where needed writing test code that shows the actual behavior of ambiguous interfaces

Investing  the effort to understand not just your code but the interfaces you have available will save time and effort in the long run.  Often this kind of investment is pushed aside by more "urgent" tasks, but this is one of those times you must find a way to get "important" tasks done, even if they don't feel "urgent" at the moment.

                                                                                 copyright 2007 Kerry Champion

January 19, 2007

Congratulations! It is do-or-die time. What now?

So you have just been given the burden opportunity of managing a high profile software development project with an aggressive set of goals that are critical to your organization’s future success. A true “do-or-die” project.

The expectations have been set high. The time frame is short, the feature content is ground-breaking, the competition is moving quickly to leap-frog over you, and the customers have critical needs many of which have not yet been uncovered.

Cool! So what do you do now?

Certainly step one is to make an assessment of the state of the project, where one of the key things you are looking to learn is: what is within my control and what is outside my control. You almost never have the luxury of putting everything on hold while making that assessment, so this will need to be an in-flight evaluation. (A later post will discuss this process.)

You will discover a dispiritingly large number of things that are outside your control. But there is one thing certain to be in your control: how you will behave, what example you will set for others.

Luckily that is the one thing that will matter the most to your sanity. This is a project that will consume a meaningful chunk of your life. You will accomplish more and feel better about the experience if you have a directed conscious agenda for how you get things done.

Sometimes you get things done by proactively defining what issues need attention and then pushing those to the front-burner. Other times you will reactively respond to issues raised by others. The accepted wisdom is: Proactive = Good, Reactive=Bad. Two interesting points about this truism: first it is not always true; second when it is true it is almost never fully put into action.

90% of the time falling into a reactive management mode is the wrong thing to do. Yet there are exceptions, for example if you have a solid team in place with good candidates banging on the door to join, and your product is being caught up into a tornado of user acceptance then it very well may make sense to respond to the obvious issues that are right in front of your face and scramble up the user acceptance curve as fast as you can go. Moore’s classic Inside the Tornado does a good job of describing this state.

Remember though riding the tornado is the exception, even teams that do eventually “bang it out of the park” can spend long stretches of time pushing to get all the right pieces in place. The fact that you were just given the burden opportunity of managing this project suggests there is something that needs to be fixed before you get to that whirlwind of user acceptance. If nothing needed changing no one would shake up such a critical project by putting a new manager in place.

So you know change is required and it makes sense that a conscious proactive effort is the right way to approach that change. What then are the seductive forces that so often pulls managers into a reactive mindset:

  • Confusion of the urgent and the important      

  • Wish based planning       

  • Misunderstanding what it means to support your team       

We will talk about each of the above in coming posts.

Having navigated around the above landmines and completed your assessment of the state of the project you are ready to start you informed proactive management of the team. What now?

You can start by doing following the time-honored maxim: “when in doubt – create a PowerPoint”. A presentation covering the key topics has some advantages:

  • by writing it down you are forced to think clearly about the issues     
     
  • the presentation format means a minimum number of words which means a minimum amount of time spent on crafting and wordsmithing the document itself
     
  • having taken the time to create a “presentation” you will feel a moral imperative to actually show it to somebody. No matter how salient your insights they really have no value if you don’t test them, evolve them and put them into practice, To do that you most communicate them early and often, hording them for a special occasion tends not to work as well

The topics to hit in this first presentation depend on the specifics of the project. Generically there are three things you will want to cover:

  • Do you have the right people on the team?    
     
  • Have you articulated a set of defining questions/actions/results?           
       
  • How will you refine your process, so that with each turn of the wheel you get better and better at what you are doing?        

We will talk about each of the above in coming posts.

                                                                                 copyright 2007 Kerry Champion

April 2008

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Blog powered by TypePad