Don't let Knowledge Walk Out the Door

In a recent post I sounded off about needless complexity in Information Systems and pointed out how it creates, among other problems, a huge knowledge burden: it gets more and more difficult for anyone to understand the system. But even if you try to keep it simple, making sure you have an adequate organizational knowledge base to manage your information system - your hardware, software, website, database, and processes - is quite a challenge. The boundary line between the technology and business practice is a domain where the knowledge problem is particularly hard to manage - because the IT staff cannot get this knowledge from any single source. For example, we as software developers can document how our routine to automatcially draft monthy dues from members bank accounts works, and how to use it. But we do not necessarily know what day of the month an organization runs it on, or how long their bank takes to process it. So IT staff may feel they have this monthly process well documented - but when the staff member who has been running it walks out the door, and a new person takes over, problems arise, people are billed incorrectly, and suddenly something that had been running smoothly month after month seems out of control. A key staff member quitting like this really exposes a knowledge gap. But there are numerous early warning signs for us that this boundary area is getting out of control. Users ask for specific business rules to be added to the software, and then sixty days later request they be removed. Users will create user-defined fields and then next year ask us what they are for. Sometimes we get the same question over and over again from the same organization - clearly it has become a problem for them to keep track of the answers we give them The knowledge challenge is increased when multiple outside consultants are involved in critical projects - maybe one group doing the business and relationship management software, another group working on the website, and a third coming in to do network maintenance. In this case it can even become a problem just to track who did what work. The other day, a client called, trying to track down documentation for the scripts that pulled data from our application out to his website. The problem was he didn't know whether we or the web designer had written the scripts, so he did not even know where to turn for documentation. It's not that he is disorganized - he's new, he's the net admin, and he was left with no internal resource to find out who did this work. You may be buying services from a lot of assistance providers - but it is your organization alone that is ultimately responsible for being able to retrieve working knowedge about the system. It's just like your health: you may see various specialists at your HMO - but really its up to you to remember you have diabetes. Your IT folks are already overwhelmed and understaffed - how can they rise to this documentation challenge? I have an idea I will share in the next post in this series. I think the secret to building an organizational IT knowledge base with minimal cost to the organization is the efficient re-use of documents that are already being routinely exchanged as your system grows and changes. Tags: nptech, km

Mountains beyond Mountains

Sorry to have been away from this blog for so long... but I spent all of last week in bed battling what started out as a cold but morphed into a case of pneumonia... today at long last I feel sort of human again... Speaking of infectious disease, while I was cooped up I read Tracy Kidder's Mountains Beyond Mountains, the story of Paul Farmer and his Partners in Health organization. We often hear Margaret Meade quoted: "Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has." Kidder's book shows what this means in real life. Paul Farmer set out to bring health care to the poorest of the poor on the central plateau of Haiti, and managed to pull much of the world heath establishment into his venture. Despite Farmer's explicit refusal to consider cost-efficacy as a morally acceptable construct in health care, he and his cohorts managed to drag much of the global health care technocracy around to his way of thinking, and reshaped the way major organizations -- like the World Health Organization -- think about the treatment of tuberculosis, AIDS, and malaria in the most desperate parts of our planet. Not that many years ago, Farmer was a voice crying in the wilderness about the danger of multiple-drug-resistant tuberculosis - but just this week the WHO took his approach to malaria, calling for an end to single-drug treatment of the disease before it breeds more virulent and resistent strains. But most remarkable is the man himself -- his story, as told by Pulitzer Prize winning Kidder -- shows just how much energy and passion can be channeled by a single human being -- and just how much good can be catalyzed by a single passionate spirit. Technorati Tags: nptech, healthcare

A Disruptive Innovation of the Heart

Martin Luther King's birthday is now a holiday... but how do we as technologists use it to further the American dream of justice and equality? I came across this in a blog posting by the poet Charles Chatmon: ...our children will be told part of the story, but not the whole. They'll be told that Dr. King won the Nobel Peace Prize; but won't be told he was stabbed, they'll hear from pundits how elegant and powerful his speeches were, but failing to realize the huge opposition he faced in taking his successful movement to the Northern cities where politicians denied his efforts at every turn. And Dr King himself reminded us of the danger of half-hearted support for social justice in his Letter from the Birmingham Jail: I have almost reached the regrettable conclusion that the Negro’s great stumbling block in his stride toward freedom is ... the white moderate, who is more devoted to “order” than to justice; who prefers a negative peace which is the absence of tension to a positive peace which is the presence of justice... So children: Why was there so much turmoil around an effort we celebrate today as American as apple pie? The Civil Rights movement of the 1960's is often presented as an incremental step in realizing America's promise of inclusion for all its people -but that's not quite right - because it was what we technologists call today a disruptive innovation, in which existing structures had to give way as new behaviors swept the "marketplace". So let's remember that in society it works just as we've seen it does in technology: a little disruption goes hand in hand with innovation. In the coming year, let's not be afraid to the rock the boat just a little when we see or hear something that we know is just not right. I'm just talking about opening our mouths, venturing an opinion, being as outspoken about human rights as we are about the latest changes in web technology or the search engine wars. Let's be the innovators we claim to be! Tags: nptech, MLK

Technology Challenges

We need your input! Back in October, TechSoup held an online forum on Web2.0 for non-profits in their Emerging Technologies forum. The discussion there led to some interesting offline conversation about "what REALLY ARE the pressing technological needs of non-profits at this point in time?" And what we decided is - we want YOU to tell us. So last month I spent some time working with Malin Coleridge at TechSoup to put together a questionniare on Technology Challenges Facing Nonprofits. You can find it here. As an added incentive to participate, each organization responding by Feb 5 has a chance to win a TechSoup t-shirt and your choice from a selection of software packages generously donated by Macromedia!! But please, only fill it out once per organization!! Tags: nptech, techsoup

Another view of this 2.0 thing

As you know, I've always been cautious of the marketing frenzy around "web2.0" even as I evangelize among non-profits for the use of some of this newer technology. I'm not the only one wary of the buzz. For example, I enjoy following the discussion in EDS's Next Big Thing blog. Coming from the heart of a major "old-time" tech company, the contributors here often have a different take on things from all the writers focusing on small tech firms we so often quote. EDS fellow Charlie Bess, writing this week suggests the "Web 2.0" is not really a wave of significant innovation, but a period of consolidation. Tools like Ajax, RSS, XML he sees as "refinements" of innovations from the .com period. Most of the things I see listed as Web 2.0 appear to be incremental improvements and not the radical changes that will be coming from more of a context computing approach, based on location, role, time, function ... So what does Charlie want? In a related post several months ago, Charlie makes it clear that while Web2.0 techniques like Ajax access data more dynamically, the real paradigm change in his book will be when browser "pull" is replaced by push technologies. The Web 2.0 concepts are focused on using data dynamically but in a pull fashion. Even though the [O'Reilly article] describes RSS as a push technology, I just don't see it that way. Turn off the refresh of your RSS reader and no new content - that's pull by my definition. Charlie is also waiting for context-aware computing, where the application will know from the user, the time, the room the workstation is in and so on, just how to react to an input. Another developer critical of the millennial tone of web 2.0 evangelism is Brady Joslin. His criticism comes from a different source. Last month in a post called "Quit with the Web 2.0 Silliness" he wrote "Web2.0 is as stale as Y2K". Cold, eh? His concern is that while indeed some new techniques have come into use, simply using them does not necessarily provide better applications: The Web 2.0 buzzmachine would benefit from being a bit more critical of new web services. Don’t blog about Ajaxy sites just because they are Ajaxy. Communities sites don’t mean anything if they aren’t sustainable. A mashup isn’t cool just because it uses data from different services - does the service provide real value? Most importantly, just because a site does not employ the latest trends, this does not make it less valuable. Conversely, it is the elegance and efficacy of the chosen implementation techniques that matters, not the techniques in isolation. So why all this hype if the technology is not really all that brand new? James Lewin, writing in Small Business IT World, suggests it is a business response to the .com crash, a way to keep investors interested in web-based business: The concept of "Web 2.0" is pure marketing. It was created by O'Reilly Publishing and MediaLive International when they were brainstorming conference ideas. They wanted to capture the idea that, far from having "crashed", the web was more important than ever, with exciting new applications and sites popping up regularly. What do I think? I think users and technologists alike should be focusing on usability, flexibilty, and the addressing of bonafide organizational and business needs - not on the ability to stake a 2.0 claim. The new tools available in the last few years are very exciting - but is there really a web 2.0? The technologies grouped under that rubric are just a collection of recent newsworthy tools, techniques, and software features. Tagging, for example, is not a technology at all - it's just a program feature. We provide for tagging of people, organizations, and tasks in our Windows-based CRM. That can't be Web2.0 - it's not even in a browser! Tags: nptech, web2.0

IT Planning with Scrum

There's a book that made a big impression on me a couple of years ago, and changed the way I manage a number of my software projects. The book is Agile Software Development with Scrum , by Ken Schwaber and Mike Beedle. The book presents an approach to software project management that, with some changes and adaptations, I've found useful in working with many of our ongoing clients. In a minute I'll give the a five-minute intro to Scrum... but here's why I'm thinking about it today. I happened to be glancing at the Wikipedia article on Scrum, and noticed the following comments: Its intended use is for management of software development projects....However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding. Reading this, it dawned on me that the elements of Scrum might make a fine framework for managing the IT projects of a non-profit organization. I often hear organizational staff complaining that they just don't seem to get it together to carry out some of their long-term IT goals. I see groups trying to develop training manuals, or bring their webserver in-house, upgrade various applications, and so on. I'd bet Scrum, with its emphasis on frequent short cycles in which specific improvements are made might be of help in this situation. The purpose of Scrum. Along with other practices developed by the Agile Development movement, Scrum evolved to create a structure for modern software projects which take place in changing business environments with short lead times and continuously morphing requirements. The old approaches to application development seemed not to be working anymore: development staff were finding that by the time they had designed and built the elaborate systems being requested, they were already obsolete. No matter how carefully and quickly they worked, they always were fighting a backlog of requests, users always wanted stuff faster than they could deliver, and the change requests never stopped. Sound familiar? Scrum is an attempt to accept and work in this environment, rather than deny it. The Elements of Scrum The Sprint. Scrum sees a project advancing in controlled spurts called Sprints. A sprint lasts about a month. We have found three-month sprints work well too. At the beginning of a sprint, the tasks that will be included in the sprint are selected by the team. The "team" therefore includes key users as well as the project staff doing most of the work. The items should be realistically chosen to be do-able over the duration of the sprint. This kind of planning feels quite different than selecting the tasks, and then estimating how long they will take. The Backlog. Where do the tasks come from? As requests from users arrive, as they inevitably do, they are put into a list of tasks called "The BackLog". A task should be bite-sized: between 1/2 to 2 work-days to complete. So complex tasks need to be broken into their components. It may be that you do not know how do to this, so maybe the only task that can be entered at first is "Figure out how to approach that complex task". Someone needs to be responsible for keeping the backlog and entering requests into it. Scrum refers to this person as the "Product Owner". This is the person with primary responsibility for getting this team to function properly. The Sprint Planning Meeting. At this meeting, the team determines which items from the backlog are to be included in the next sprint. In getting ready for this meeting, the "Product Owner" may need to work clarify the meaning of requests, and get estimates from team members for the how long each task will take. Key stakeholders need to be at this meeting, so that the delaying of items to a later sprint is understood as a team decision. Daily Scrum Meetings. The team meets every day for a very brief meeting (maybe 15 minutes) to share what they are working on and what difficulties they are running into. These meetings are the responsibility of the ScrumMaster. The ScrumMaster is also responsible for trying to resolve everyone's difficulties as well as possible. This may mean coordinating logistics, making purchases, reassigning tasks, arranging a walk-thru with users, and in general assisting the rest of the team in anyway possible. As the Sprint draws to a close, the daily scrum meetings serve to make decisions such as the actual date to end the sprint and what requests if any need to be dropped from the sprint due to schedule overruns. Sprint Retrospective. At the end of each sprint, the entire meeting briefly discusses how the sprint went, and what to do differently for the next sprint. And the process begins again. The Advantages of Scrum for IT teams User acceptance of schedules. Users are actively involved in determining what features are included in each sprint. Since sprints are of equal length, there is no "real soon now" or "as soon as we can get to it" - its "Should we do this next month or not?" Set up wireless network. Next month or not? Bring our web server in house? Next month or not? And involving all stakeholders in each sprint plan reduces pressure on the IT department. Perceptible improvements. The team can win increased support from users by showing a steady stream of perceptible improvements. Instead of users waiting an uncertain time for uncertain gains, they see specific improvements to their IT infrastructure each month or quarter. Planning made possible. Since only a month worth of work is committed to at a time, up-front planning is more realistic and immediately useful. More complex planning tasks are backlog items to be done like any other, not first steps of that prevent the scheduling of work. Transparancy. Daily Scrum meetings encourage honesty about problems, delays, and difficulties that may be encountered on the way. So there are fewer nasty surprises. Indeed, Schwaber considers this openness a key value of the scrum approach that contributes to better quality. Agile and Xtreme methodologies have created a lot of excitement in the software development world in the last five years - there's no reason not to move these approaches to the daily tasks of technology management. Tags: nptech, tech_planning, scrum