Where do solutions come from - our first release

In previous posts I wrote about an initiative we are working on to change the way we engage with our users. Our first release toward this goal is planned for the end of this month and the team has made great progress and will achieve our release goals. Our goal for this release is to begin seeding a virtual community space (a simple blog for now) with content to help people visualize what the community can be. Our thinking is that if the content is compelling people will begin gravitating to it. When this happens we can have a set of people that feel strongly about the content and the forming community that we can then work with to help determine how best to evolve the platform to meet the communities needs. As we provide better tools we hope to have the community take over and move forward on their own. Once the community takes over, openly discussing how they work and sharing ideas with each other, we can hopefully learn more about what truly matters to them and find new and better ways that IT can impact the way they work.

Value in simplicity

In looking through my Twitter stream the other day I came upon an interesting tweet from Andrew McAfee pointing to an article in Wired titled The Good Enough Revolution: When Cheap and Simple Is Just Fine. It's an extremely insightful read, especially in light of the work I referenced in my recent posts around finding solutions to user problems. If I could sum up the article into a key takeaway it has to be the paragraph below:

The world has sped up, become more connected and a whole lot busier. As a result, what consumers want from the products and services they buy is fundamentally changing. We now favor flexibility over high fidelity, convenience over features, quick and dirty over slow and polished. Having it here and now is more important than having it perfect. These changes run so deep and wide, they're actually altering what we mean when we describe a product as "high-quality."

I believe this concept applies to enterprise IT products and projects as much as it applies to consumer products. IT projects can no longer be mega-projects that deliver overly complicated solutions that attempt to solve every conceivable problem, real or perceived. Instead we need to be quick to market and deliver focused solutions that solve a small number of the right problems. What I think is also important to note is the interpretation of "quick and dirty" and what is meant by "having it here and now is more important than having it perfect". To me, in the context of this article and enterprise IT, "quick and dirty" means a short time to market and delivering the simplest possible solution that solves the right problem, or at least the most important 80% of the right problem. Quick and dirty does not mean cutting corners or sacrificing technical quality (e.g, bugs, poor performance, poor code quality, etc.) to get products out the door. Similarly having it here and now rather than having it perfect does not refer to a lack technical quality but to the need for quick delivery of a product that targets a single or small number of the key problems in an extremely easy to use manner and does nothing more.

I recommend reading through the whole article and also Andrew's blog post on the same topic.

For me, these articles re-enforce the notion that we need to truly understand how our users work and the issues they face in day to day work so that we can solve the right problems and understand what quick and simple solutions could be.

What users really need

I came across this blog post entitled "What is User Experience Design" by Alla Zollers a PhD student at UCLA in the department of Information Studies. The post is the authors quick overview of user experience design. In reading through it I came to the following section that highlighted exactly what we are trying to achieve with the initiative I highlighted in my previous post, Where do solutions come from?:

... when Henry Ford built his first car, he was quoted as saying “If I’d asked my customers what they wanted, they’d have said a faster horse.” A company’s job is not to give users what they want, but to solve problems. The problems that companies are trying to solve are usually social, and so understanding people and how they interact with each other and their environment forms the key understanding and driving force of the product design and direction.

At the core, user experience advocates for the end-user and makes sure to bring the customer’s perspective into the decision making process. In order to achieve this user-centered approach, user experience designers engage in several activities:

• Observe customers in their natural environment to understand how they are currently interacting with existing systems, as well as get insight into how users view the world (their mental models).
• Build empathy and understanding of the customers within the entire product team

The rest of the post goes on to provide more insight into User Experience Design and it's business benefits, but it is the section above that I believe truly explains exactly what we are trying to do.

Improvements in application support - update

In late 2008 I worked on and blogged about an initiative to improve our application support function. While that initiative has been successful in implementing a new way of supporting our applications and we are in the process of moving our applications to the new model there is something else that I would like to acknowledge. In addition to testing the changes that I described in my blog post last year we also implemented some large changes in our existing support team to more immediately address the same issues I described in the earlier blog post. These changes entailed streamlining the team and asking them to shift their focus from "fire fighting" to:

1. collaboration and learning
   
2. root cause analysis
   
3. continuous improvement
4. making support a fun place to work
   

The idea was that we had some quality issues with our applications and our application support processes and the quality of service our users were receiving was impacted. We wanted the support team to identify the root causes of those issues and work with our development teams, other support organizations and sponsors to address the issues and make our applications more supportable while also making application support a place where people are happy to work. Well it's been about a year now, the team is in it's fourth "release" and there were some interesting things presented at today's sprint review:

1. the July year over year support ticket volume has decreased by approximately 30%
2. the first item presented by the team was the number of hours of support team member savings per month that were generated by the support and development teams focusing on continuous improvement activities
   
3. support ticket backlogs are higher than the team would like

My observations on these are:

1. the year over year decrease in ticket volume is great progress and validates our hypothesis that we had issues that could be overcome. It also makes me ask the question why can't we reduce an additional 30%, 40% or even more?
   
2. the idea that the amount of person hours savings was the first thing presented by the team confirms that the team has clearly and decisively transitioned from "fire fighting" to a value add team that is focused on making our applications more supportable
3. while support backlogs are higher than the team would like (we did reduce the team size quite a bit) the focus on collaboration, continuous improvement and root cause analysis should not decrease. The long term gains that we see from these efforts (see bullet 1 above) are much greater than any short term blips in support ticket volume increases, especially when we collaborate and communicate effectively with our sponsors and users

Needles to say, both of these initiatives have led to interesting findings on how we perform application support and development and will definitely help us think about how to improve in these areas going forward....and I will keep blogging about it as we progress.

Where do solutions come from?

I am working on an initiative that is looking to improve the way we engage with our key, front line users when developing IT solutions. Our key user base is highly mobile, global and has very little discretionary time. To be effective and widely adopted, the solutions we deliver need to have clear value propositions, need to be easy to use and generally not require big behavioral changes. Given the complexity created by all of these factors I think we have done a good job in identifying value add solutions that can help these users be more effective and efficient. With that being said, I do believe that there are opportunities out there that remain untapped. The reason being, in my opinion, is due to the way we engage with these key users: typically somebody has an idea for something that might be a good product and then we follow it up with a period of user research validating how that idea could be implemented. I think this approach works but we can improve on it by finding new, different and better ways to source the initial solution ideas. The way we are trying to do this is by listening to our users. Not by asking them questions about a specific product idea but by listening to them talking to each other, sharing ideas, tips and tricks and advice and asking questions of each other. From this we hope to get insight into how they work and the types of issues they face and put ourselves in a position to identify simple solutions that have the potential to help these users. Success is an active community of users openly discussing the things that they do on a daily basis and the tools and techniques they use. With this dialog should come valuable insight into how our users work and what helps and hinders them. Its exciting stuff and has the potential to provide us with a wealth of knowledge that will hopefully lead to greater value for our users. Needless to say I am excited by the challenge and look forward to blogging about what we're learning and the progress we are making. Any feedback would be great....just leave a comment.

Top software development books

Jurgen Appelo at noop.nl created another great list...the top 50 new software development books. The list includes books covering various aspects of software development: project management, business analysis, user experience, testing, refactoring, agile practices, architecture, web services, etc. The list was created using a weighted list of the following criteria and includes books that are less than two years old...

• Number of ratings on Amazon.com
• Average rating on Amazon.com
• Number of ratings on GoodReads.com
• Averate rating on GoodReads.com

Note: The time that has passed since a book's release date was part of the calculation. For example: A book that got three 5-star ratings in just four months is listed higher than a book that got the same ratings in a much longer period of time

The power of really good software - part II

My exploration of SugarCRM continues. Being impressed with what the application could do we decided to explore if it could meet the requirements of another stakeholder group. This required an even deeper dive into the application and I must say that even after taking this dive, I am still impressed with the application!! First off, let me start with what is really cool about open source. I was able to download this application, get it installed and not only try it out but dig through the code, the web services API and just about every aspect of the application. This makes the decision to proceed with an implementation much less scary because you can get a far deeper understanding of the application than any sales demo could provide. So, what did my digging turn up...well, one of the key requirements was to be able to email into the application and have those emails tracked against the Contacts that were included on the email. After reading the documentation, which is just as good as any vendor product documentation I've ever read (and once again I had access to it without having to spend a nickle), it was clear that the out-of-the-box application did not do what I needed to do. My next step was to search through the plugins and open source add-ons to see what I could find. I did find a Connector that could be integrated into our Lotus Notes client but it was to intrusive for our liking. The next option was to write a script that could read emails from a mailbox and load those emails into SugarCRM. This looked like a good option so I dug deeper. This digging led me to the SugarCRM SOAP API. This is definitely another area where I was impressed. My first thought, however, was to be very scared because I read quite a bit about SOAP and SOAP based web-services and I was expecting quite a challenge. Far from it, while dealing with the SOAP Message response objects took a little figuring out, calling the API via my Ruby script was fairly easy (I'll do another post on the power of Ruby and SOAP, following this one). The API has get_entry/set_entry methods that more or less let you create and search for any record in the application. Getting a hang of these methods basically allowed me to do everything I needed to do....and also made me think of a ton more things I could do if only I had the time! All-in-all I am thoroughly impressed with SugarCRM and more importantly I have changed the way I think about evaluating vendor applications. Having the ability to run an application through it's paces (both technically and functionally) without the need for sales reps, contracts, etc....is definitely a new requirement that I will add to my list of vendor selection criteria in the future. My guess is that this will lead me to many more open source applications!!