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.

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.

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!!

The power of really good software

I am doing some research into SugarCRM and I am absolutely amazed how simple it is to install, configure and use. SugarCRM is an open source CRM package and according to their website:

SugarCRM is rethinking how technology can help companies manage customer relationships. Sugar, the market leading commercial open source CRM application, delivers a feature-rich set of business processes that enhance marketing effectiveness, drive sales performance, improve customer satisfaction and provide executive insight into business performance. Supported by deep collaboration and administration capabilities that adapt to how your company operates, Sugar is delighting customers of all sizes across a broad range of industries.

The need that we are looking for SugarCRM (or any other similar application) to fulfill is to track interactions with a set of people. This is obviously a very small subset of what SugarCRM can do. As a result, the goal of my initial evaluation was to see how easy it would be to get a simplified version of the application in front of key stakeholders and get some feedback on whether we thought it was worth proceeding. In less than 1 hour, I was able to download the entire application stack (Apache, MySQL and the SugarCRM application) and get the application up and running locally on my workstation. Of the hour I spent, these simple steps took about 10 minutes, of which approximately 5 minutes of that was spent waiting for the software to download. In the remaining 50 minutes I was able to login, get a pretty good feel for how the application functions and actually configure the screens and tabs users see and add and remove fields on screens. None of my time was spent reading documentation or user manuals. Instead I was immediately adding value: making changes, testing them out and then making some more changes. Configuration changes are simple drag and drop exercises and saving and deploying changes is as simple as pressing the "Save and Deploy" button. Understanding how to use the application was just as easy and within minutes I was adding data and navigating around the application with ease. All in all, the experience was an absolute pleasure and I believe that after that 1 hour of work I have a good enough sample that I can share with stakeholders to figure out how to proceed. What a great example of software done right!! And the best part....it's FREE!

Impact of the economy on PMs

Josh Nankivel at PMStudent.com created a survey that asks participants

What impacts on project management (in particular) have you seen from the state of the economy?

A slightly revised version of my initial response below:
In the world of software development within enterprise IT, with less money available for projects, teams are asked to do the same or more with less....less money, less people, less tools, etc. The PMs who will be the most successful in this climate are the ones who do more than just manage. Those that can lead, inspire and motivate, those that can innovate, those that can break down barriers and remove impediments, those that can teach and mentor and make others better, those that can pitch in and code or test or prioritize requirements or help solve problems when necessary, those who can get stuff done by building empowered and enabled high performing teams will succeed.....come to think of it, these are the people who will also be most successful when the economy is strong!

Interview questions for software developers

Jurgen Appelo, CIO at ISM eCompany and author of the NOOP.NL blog, posted a list of 100 interview questions for software developers. The list includes questions grouped by knowledge areas like Requirements, Project Management, Testing as well as Functional Design, Technical Design, Construction, Data Structures and Algorithms so it should apply to PMs, BAs, Scrum Masters and Product Owners as well as Developers and Architects.

Going through the questions and thinking about how I would answer the questions was an interesting exercise that I would recommend for others. Some of my favorite questions:

1. How do you treat changing requirements? Are they good or bad? Why?
2. What do you do with requirements that are incomplete or incomprehensible?
3. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
4. How can you reduce the user's perception of waiting when some functions take a lot of time?
5. Which tools are essential to you for testing the quality of your code?
6. What measures have you taken to make your software products more easily maintainable?
7. What can you do reduce the chance that a customer finds things that he doesn't like during acceptance testing?
8. How many of the three variables scope, time and cost can be fixed by the customer?