Last month, I was listening to a discussion about QA, SAAS and cloud computing, thanks to Dan Carr, Executive IT Architect in IBM. One of the items discussed was a term called non-functional requirements.

We all know what functional requirements are, and the prolonged discussions in meetings about functional requirements. Non-functional requirements are items that remain the same in information technology offerings irrespective of the product features. Few of the non-functional requirements are: availability, reliability, disaster recovery, security, scalability, backup, performance, data portability, manageability and configuration. According to this school of thinking, the more things change, the more they stay the same.

I think non-functional requirements are the most undocumented requirements and are hard to for teams to organize and plan for. These requirements consume more energy and resources from the available pool, yet are not brought into mainstream planning. I recommend to readers of this blog to try to find, list out and estimate resources spent to meet these non-functional requirements. If you are surprised with your findings, I recommend reading the service level agreements signed by your team and organization and how your customers rate you as a vendor. If you have a unique way of planning, allocating resources and meeting these non-functional requirements, I invite you to share the challenges faced by you and your team.

Finding the correct technology tools that help get the job done is one of the challenges in organizations. There are interesting questions when I think about this: do we need to know a tool in depth first? How will we know if the tool meets the requirements? How will we know what else that tool can do? What is a fitting decision? Buy a tool that has some capabilities now? Wait longer for a tool that has all requirements? At what price?
 
In the last year, I was looking for different tools for deployment planning and related housekeeping. Each and every one of the requirements made me look for tools that has good data base management, great user interface, easy to arrange content, make it available over web, move data around and provide different views for individuals performing various operations.
 
I looked at tools that I have not used, used a little and a few in which I have in-depth understanding. I looked at tools used by peers. In the mean time, I selected a tool that I know has some of the capabilities, dived in and solved a few problems and questions that were taking some of our time. I am finding out more and more as I go along.
 
My recommendation to teams looking to improve planning and communication is understand existing tools, understand what others in your organization and peer group in industry are using and go out and find tools. Explore it, get down to details, ask a team member to explore it and use the tools yourself, to see what the capabilities of the tools are. It is one way to find out what else a tool can do, and the more interesting part it is, to find out what else you can do.

More and more teams are adding members who work from home, telecommute and who are part of offshore development. Prolifiq is going through this phase.

One of the challenges is having a detailed technical discussion over the phone. We are learning this path of communication now. One member says something and three others on the call from three locations simultaneously start talking. How do we know if the other person has completed what he wanted to say or whether it is just a moment of pause? If we wait too long for everyone to complete what they are saying, we may forget what we wanted to say or ask. How do we intervene? How do we know if the other person on the line is thinking 'any ideas from anyone?' Did anyone have a great idea that was left unsaid because there is no face time, or they didn't want to intrude or they didn't know what was going on at the other end?

As I watched this process across different technical discussions, I see one approach helping more. One of our development team members, who has been working from a different city for many years, waits that one extra second longer to allow the others to start speaking during these calls. What do we do to learn something like this or how do we learn the other skills needed? When someone says ‘oh I see it now’ or ‘I got it’, how do you know which one they got or how do you keep everyone on the same page?

Even with LiveMeeting sessions helping everyone look at the same source code, design, or written description during technical discussions, I think we may miss getting the maximum benefit out of these meetings. I think there are many other dimensions to having a successful technical meeting over the phone when participants are in offices at Beaverton, Bellevue, San Francisco, and Singapore.

I am wondering if marketing teams face similar problems when designing marketing materials over phone? I think more and more technology teams are switching to these kind of sessions. I know for sure we are. Many of these meetings are cutting edge design and decision making meetings. How do we know we reached the best possible option?

What did you or your team members do when learning this process? Or do you have a magic team that just switched gears?

We, everyone working in software, work now with individuals who are from different parts of the world. We communicate now over email and instant messenger with vendors, co-workers and customers whom we have not met in person yet and may never meet some of them in person. There are many challenges in this environment. How can I learn about a person or group from a different culture, from a different way of living, who work-from-home, work late night, work off-shore, etc? How do I communicate about myself to persons from these groups? Can I ever master information about any or all of these? What if I learn 5 different languages? I would like to share with you a real event in this post that relates to these thoughts. My recommendation: always ask explicit questions and act explicitly when you are in doubt; especially when you think you are trying to help in a different environment.

This happened when one of the IT consultants working in software industry travelled on a business trip. It was the first trip ever for that person outside the country. Like every other industry, I think this has been happening a lot now for people from all corners of the world on IT missions: sell software, develop software, deploy software, support software, etc. After a long business day in a new country, the consultant went out exploring the city in the evening. There was a restaurant with options for dining in or taking out the dinner home. The consultant went inside and tried to understand the menu and takeout orders.

The consultant found that the restaurant served dogs. The consultant has dogs as pets and was shocked. Well, shocked is an understatement. People were ordering dogs that with the intent on cooking them at home. The consultant wanted to save a few dogs and ordered two dogs to take home. Then an idea flashed in the consultant’s mind and he checked his wallet. Called the waiter and calculated and found that there was enough cash in his wallet for 10 dogs. Changed the order, included few puppies and the count was changed to 10 dogs instead of 2. Started thinking about how to fly the 10 dogs back home and keep a few at home and present the rest as gifts to friends. After some time, the waiter returned with the fulfilled order. All 10 dogs silenced permanently and packed in a large takeout box. That was how the restaurant understood the order. The consultant was devastated. Communicating intention of the buyer was missed. How many of us believe that language is not the barrier when we want to show our love for dogs? If language was not a barrier in this event, why should it be in other situations?

Here is my explicit question: what was the latest challenge you faced when working with people whose native language is not your strength? If readers have communicated successfully or faced problems in a culturally different environment than the ones they familiar with, I would like to hear.

Deployment

Deployments for software-as-a-service have many challenges, like every other field. I will be sharing some of my experiences on deployments in Prolifiq. So for my first post, I wanted to discuss a couple topics: impact of business priorities on deployment, last minute additions to deployment items, selection of items for deployment, treating every deployment item on its own merit and how it good it fits in the environment, risk analysis, rollback plan, roll out of deployed features in phases and a unique team.

Deploying a replacement for an existing application with additional features
Recently we deployed a new application from a different software vendor that replaced an existing component of our service. We evaluated choices from several vendors and selected one. The one we did not select needed integration of applications from more than one provider. The response time of pre-sales team from another vendor did not suit our time frame and our team’s capability to move faster.

My recommendation to technology pre-sales and sales teams: do not take three weeks to send evaluation versions. Especially when the buyer says the evaluation will be done in four weeks and a decision will be taken at the end of fourth week! Our business priorities needed all the pieces and within a specified time frame. After couple of weeks we selected the new application from vendor 1. We are happy today that we made this choice.

During this deployment we got reminders from nature about bones, streets and homes. It was Christmas/New Year holiday period. The Prolifiq team is all over the world including Beaverton, Bellevue, Chennai and Singapore. Record snow fell in Oregon and Washington, disturbing everyone’s schedule during the deployment weekends. Our deployment team members in Bellevue were excited to see a foot of snow and ice, so decided to become explorers like Lewis and Clark. Unfortunately, they got trapped on the street on their way to the office. My recommendation to deployment teams: Lewis and Clark-types are great to have on a team, but encourage their exploring to the indoors on deployment day!

Our team members in Chennai and Singapore helped us in faster turnaround of feedback loops on features, development and quality assurance. When it was late night in Pacific Standard Time during deployment, our team in Singapore was fresh with morning coffee and provided the energy that kept the team going.

Since this new application runs on a different platform compared to other pieces of our system, we deployed this application in four phases. First phase deployed the backend piece that had just the engine. Second phase deployed the database piece that processed the data from this engine. Third phase moved our internal customers to validate both. Only when we confirmed that these pieces worked well with the rest of the system, did we roll out the new application and its features in the fourth phase to our customers. In all, we learned a lot in the four phases about this new application and how to make it fit into our service. We have also deployed other items during these phases. Some of these are directly related to this application and a few others are different parts of our system.

Our rollback plan was a) the old application is still running as before and we can switch customers back to this old application anytime. b) deployed in phases to limit roll backs. This varies. We needed this approach for this deployment. c) dog food, what I call eat the food we are serving before rolling it to customers. We did this. If there was a rollback or problem, only internal customers would have experienced it. d) we rolled it out to one set of customers first. This is one of my all time favorites: there will always be something new in the usage pattern of features by customers. There will be things to learn as we go. We adjusted a few things after studying the usage pattern of the first set of customers before rolling it out to the next set of customers. We are still learning with the latest set of rollback to another set of customers.

I welcome your comments on the above and look forward to hearing about some of your experiences on deployments.