Innovation in the clouds

How cloud computing, mainly seen as a way to reduce IT costs, is likely to be a platform for widespread innovation across industries?

In their book, The Innovator’s DNA, Jeff Dyer, Hal Gregersen and Clayton Christensen reported the results of their eight-year study in which they “sought a richer understanding of disruptive innovators.” Their studies showed that innovative entrepreneurs and executives behaved similarly when discovering breakthrough ideas. The authors characterized these behaviors through five skills: Networking, Experimenting, Associating, Questioning and Observing.

It is my belief that cloud computing directly supports at least three of the five skills.

Networking: Innovators are in constant pursuit of ideas through a diverse network of individuals. They socialize and test ideas by talking to people who may radically different points of views. Their approach is in contrast to that of most organizations, which continue to block access to popular social networking sites. However, the same organizations recognize the value of information shared among those who need it in a timely manner. Cloud computing brings in the controls organizations look for while enabling users freely socialize with each other. It helps break down organizational and geographic borders and opens the door for new opportunities to collaborate with sister organizations and competitors. A recent example of this is a software that allows multiple companies to share one issue tracking system and collaborate behind the scenes while end-users experience seamless issue resolution.

Experimenting: Innovators are tireless experimenters. They try out ideas, pilot concepts and collect feedback as much and as early as possible. Failure is not a concern for them. As Edison put it, they do not fail, they find 10,000 ways something will not work.

It is almost too easy to experiment in the cloud. In the past, IT prototypes required large capital expenditures, infrastructure builds, and personnel. Now, one can buy whatever level of computing (one server or a super-computer) without any up-front investment and start using it within minutes. There is no need to estimate and budget for usage many months in advance. There is no need for time-consuming setups, personnel training, hardware/software maintenance, etc. Now, one can experiment almost as fast as one can come up with ideas.

Associating is the ability to create meaningful conclusions from seemingly unrelated matters. It is the ability to see something that is before our eyes but most (if not all) others fail to recognize because they do not make the associations.

The exponential growth of data does not make it any easier either. In addition to the excessive amount of data on the internet, most organizations have their proprietary data and information on different systems, which don’t typically connect with each other. Cloud computing, with its centralized and connected nature, makes bringing information together and distilling valuable knowledge so much easier by taking away one barrier: disconnected, incompatible systems.

I am leaving the other two skills the authors list, Questioning and Observing,  out of this article but I would be curious to hear your opinions about how cloud computing may help with questioning and observing.

What is “Systems Engineering in Commercial Organizations?”

Since I started implementing systems engineering processes and practices in commercial organizations, one of the standard questions I hear is…

So, what is this “systems engineering” anyway?

While each implementation has its nuances, the fundamental building blocks of commercial systems engineering are as follows:

1. Requirements Development & Management (RD&M)
   
2. Product Architecture
3. Design & Development Management
4. Integration
5. Verification & Validation (V&V)

Now, let’s open up each of these building blocks a bit further.

Requirements Development & Management is where everything starts. Typically delays in commercial and government programs are attributed to poor RD&M. First, not all requirements are created equal and the organization’s product development needs determine the types and levels of requirements that should be part of their processes and practices. The most common types of requirements are:

• User requirements
• System-level technical requirements
• Sub-system level technical requirements
• Product life-cycle requirements

Second, the management of each type of requirement is different from one and other because their purposes are different. Similarly, within each group of requirements, there are differences in priority and importance.

Architecture definition is the highest level solution to the set of requirements. A good architecture definition clearly shows the main components of the solution, identifies primary technologies and clearly states the interfaces (both internal and external to the system to be developed). The architecture definition should define the system to designers and developers in an unambiguous way and represent the system in different ways to different disciplines. For example, a hardware designer would be mostly interested in the physical dimensions, volume, weight, so on so forth. On the other hand, the control software developer will look for state definitions, timing diagrams, and so on. The role of the architecture definition is to anchor the system definition while allowing designers and developers freedom to conduct their art and expertise.

Design & Development Management is the act of leading the design & development teams and ensuring that detail designs meet the system-level objectives. It is common for designers and developers to lose sight of the “big picture” when dealing with many challenges of design & development. Moreover, there will be decision points where initial requirements and allocations may need to be modified and re-allocated. These decisions are mainly made according to the impact of the change on the system, which the systems engineer is responsible for.

Integration happens at many levels, from integrating resistors, capacitors and ICs on a circuit board to integrating a new service to a global organization. Regardless, the goal of integration is the same: build something larger than the sum of its components. Each integration step directly links to a V&V step.

Verification & Validation: While many people use these words interchangeably,  they have two very distinct meanings. Using an old definition, “Verification is ensuring that the system is built right. Validation is ensuring that the right system is built.” The former is checking the sub-system and the system against technical requirements to find out whether or not the requirements are met (it is built right). The latter is the ultimate test; check it out with the intended customers and markets. Does it meet their needs? Are they willing to buy it? Did we build the right system?

Done right, systems engineering processes and practices drastically improve the effectiveness of product development organizations. Done wrongly, they are just another addition to processes, practices and tools, which will be overlooked and slow down the organization.

Top-Five Tasks in Managing Small Projects

Almost all companies I consult with appear to have tools and processes set up for managing large projects. The assumption, whether stated explicitly or implied, is that large processes can be trimmed down for small projects. However, I observed in many places that managers forget to trim the general-purpose tasks down and spend time on unnecessary tasks. Further, they do so using  tools that are primarily developed for large and complex projects.

The purpose of this blog entry is to share my recent experience in managing a small project and the project management tasks & tools that helped it become a success story.

I will loosely define small projects as those where the team size is under 10 people, budget is under $1m and duration is under one year. The projects I am referring to are hardware/software/service development projects.

Here are the top-five tasks & the tools for them:

1) Actions and results tracking: An Excel-based spreadsheet that is updated regularly is the top tool for tracking actions and the responsible team members. The spreadsheet needs to be accurate, clutter-free and relevant. This is not the place to maintain the history of the project or fill it up with minute task details. Once an action is complete, it comes off the list. Follow-on actions and new ones should be added as they become necessary.

2) Schedule tracking: A simple, milestone-driven schedule is sufficient. The important point is to make the team members aware of the milestones and their role in achieving each milestone. I use a whiteboard with the upcoming (within the next 4-6 weeks) milestones in the project lab.

3) Team communication: Frequent and to-the-point team meetings and teleconferences with remote development partners help the team remain informed and up-to-date. When team members are spread all over the world, teleconference and Webex are very effective tools that facilitate this task.

4) Executive updates is a crucial part of project management, whether it is a small or a large project. I find “casual” updates to executives the most effective. These are typically done by the coffee machine or water cooler, by walking into their office, chatting over lunch, so on so forth. In addition, a one-page regular update is useful and effective because it forces the communicator (project manager) to be concise and has a better chance of being remembered as opposed to a multi-slide presentation, which typically puts the listeners to sleep.

5) Configuration management: At the project level, a top-level configuration summary is very helpful to the team, which moves fast and deals with frequent updates. An Excel-based spreadsheet is sufficient to maintain the system-level configuration. Specific configuration management tools are used by disciplines (eg. software, firmware, drawings, etc.) as part of the organizational quality procedures.

I hope you find this article helpful. If you have any questions or comments, I would be happy to hear them.

How to Keep a Team Motivated

What motivates people? Many people devoted their careers to find answers to this question. I faced the same question in a project recently and here is what I did about it.

First, let me give you a brief background. I was parachuted into a project which was experiencing issues with meeting delivery objectives and had significantly over-ran its budget & schedule targets. Among some other issues, one of the fundamental problems in the project was team motivation. What made this project atypical is that the individual team members did not lack motivation and they were not in apathy. However, the project lacked a unified team motivation. As a result, days was spent fighting fires and a new fire emerged almost everyday.

Now, let’s take a look at what motivates people at work. Frederick Herzberg, in his classic Harvard Business Review article (October 1987) shows that sense of achievement is the top motivator by a good margin. The second place goes to recognition.

With this observation, I decided to tackle the motivation issue in two steps and focus on the top-two motivators I mentioned above:

1) Immediate resolution to get things back on track and put out fires:

Sense of achievement is only possible when the objectives are clear and agreed upon. My first action was to get the team together and define the immediate goals of the project. Once we defined them and achieved consensus, we had a team objective. Next step was to identify the actions to get things back in order. Many team members already had ideas and we collectively chose a short-list of actions to take. Everything else was put aside either because they were unnecessary left-overs from earlier tasks or because they did not directly correlate with the objectives of the project.

The above approach touched both motivators:

• Sense of achievement by defining goals and, therefore, confirming that the tasks helped the team meet its collective goal.
• Recognition by using the ideas and acknowledging the achievements towards the goal.

As a result of the first step, the team met a very aggressive business milestone within three weeks and established confidence among the company executives that the project could be salvaged.

2) Eliminate future fires & keep the team marching towards a unified objective:

The next stage was to create a sustained motivation level when the adrenaline rush was over from step 1. While there was a sense of relief to meet a challenging and high-profile milestone, there was more to do to complete the project. For continued success, the team needed to know and believe in a shared vision and the way to get there. We achieved this as follows:

• Created a milestone-based project plan and assigned each major milestone to a project team member. This created a sense of ownership, which leads to a sense of achievement when they are done.
• Ownership clarified responsibility and accountability. As they are done, recognition goes to the owner and the team that made it happen.
• Access to information (i.e., communication) was spread to all levels of the project team. The earlier approach was to streamline all communication, both incoming and outgoing, through the project manager. The approach we took was to involve the full team in all incoming communication and help them communicate to outsiders their areas of responsibility.

Currently, the second step is proving to be very successful, both among the team and among company executives. Critical milestones are being met, and the project is showing signs of a healthy recovery and a motivated project team.

Beta Products – Do We Ship Today or Make One More Improvement?

Working with a high-performance and highly conscious team has its challenges. One of them is to balance the business needs with the desire to improve the product “just one more bit.” Let me be more specific: The team I am working with has a short-term delivery deadline. The deliveries are to early-adopter beta customers who are eager to receive the product, which is a pharmaceutical research instrument. Once the beta products are delivered, the project continues with the tasks to collect feedback, freeze the design, transfer to manufacturing, product launch and sales.

And, this is where the challenge is. Every day the team spends on the beta products, there is a strong desire to make the product a bit better than it was yesterday. Of course, this is the enemy of meeting our delivery date. The product is ready for beta testing in every way and, like everything in life, it can be made better with effort and time.

So, what would one do? Here is what I have done:

• Make beta delivery visible to the full team – emphasize the business (revenue) and technical (feedback on performance) benefits.
• Make delivery top-priority and pull in the support of senior management.
• Assess risks and get agreement on areas that were obstacles to the shipment.
• Display a high energy and focused attitude to remind the team the importance of delivery to beta customers.
• Park improvement ideas for future assessment and possible implementation. This way, the team knows that we are not ignoring the ideas.

This approach is working well with this team.  If you have other ideas & suggestions, I am happy to hear them. Please write to me at ferhan.bulca@intrascope.ca.

Is It So Difficult to Observe Some Basics of External Product Development?

A long-time client thought they had a very straightforward product development challenge ahead of them. They started a project over a year and half ago, expecting to finish in less than a year. The purpose of the project was to incorporate two existing products together to produce a new offering, whose value to the customers would be more than the sum of each component. One of the products to be incorporated is theirs, the other one is from an external partner.

The idea was great. The project implementation, however, was too optimistic. Shortly after the project started, I had a conversation with one of the directors of my client and pointed out the issues they may face if they tried to fast-forward a few basics of product development that involved external partners. He thought the team was on top of the situation and they had it under control.

Just recently, I received a phone call from him. The project had derailed, it was delayed way beyond its target date and the management had started to panic. With that, my involvement in the project started.

A quick observation of the status revealed that the following basics were violated:

• No clear agreement between my client and the external company on the requirements from the external company. The existing agreement is very high level and can be interpreted in different ways. The external company is very accommodating and is willing to work the issues out, which makes the situation better. However, the lack of clear definition is creating extra work on both sides, delaying the project and incurring higher costs – Not a good thing!
• There is no agreement on the verification of each company’s product to ensure the two will work together. Both parties verify as they go but the final verification can only be done at the full system level. This “big bang” approach is causing the teams miss issues until full integration and verification. At this stage, it is more difficult and costly to pinpoint the root cause and fix the issue.
• A definition of “done” was missing. This caused the teams to spin their wheels, continuously adding yet another feature, just because they could. Without a commonly understood definition of project completion, the team was disengaged and internal disagreements emerged.
• The client has an effective product development process, which provides a high level of guidance and empowers the team to make their own decisions. There are control points in place to ensure the quality and effectiveness of decisions. However, the process is taken for granted by the management. Its intent and tools are not well-understood by the team. With too much freedom but without a good understanding of the intent, some decisions led to unnecessary work and friction among the team members.
• A small project team operated on “everybody does everything” principle. While this is fine in a small and high powered team as the one on this project, some clarity in responsibilities and accountabilities was still needed.

I spent my first week on the job to rectify the above five areas. The focus was on the definition of “done,” and clarifying the process and responsibility issues in the team. With those obstacles cleared, the next step was to specify a pragmatic approach to address the requirements and verification issues. Since the project has progressed to the point where everything can be verified at the system level, there is no point in retroactive sub-system verification. With the participation of the team, we specified the next steps in verification to meet the “done” state. This exercise helped the team to focus its efforts and energize to get it done. Next, we identified who was responsible for what and resolved differences of opinions, which mostly reflected personal preferences.

In short, the first week was challenging and very productive. Now, the team sees the light at the end of the tunnel and is motivated to get there. There are other challenges ahead of us to meet the objectives and we will take it one step at a time.

Lack of Ethics in a Financial Product

The other day, I received a letter from Royal Bank of Canada, promoting a “0% interest” campaign. It states that any cash advances I would make on my credit card would be interest-free for a period of six months. Being a businessman, free money always gets my attention. Being analytical-minded, I read the fine print. And, there I find the details, which led me to write this about the ethics of product positioning and product definition.

Here is what made me think that the offer was unethical: The fine print states that any payments I would make would be applied to various components of the bill, in the following order:

1. Interest, fees, penalties – this makes sense
2. Balance with LOWER interest rate – this made me curious!
3. Balance with HIGHER interest rate!

Do you see what I see? They leave the higher interest balance to the end.  In other words, the so-called 0% promotion is nothing but! It is a method to take advantage of the trust of most people or, worse, pull those who need the cash most even further into debt.

Now, if one considers the objective of a bank, which is simply to make more money, the product is quite cleverly designed and promoted. The bank gives you a carrot and makes you pay the cheaper debt first, leaving your more expensive debt open for a longer period of time and collecting their fees, interest and whatever else along the way.

This situation exemplifies the importance of alignment between an organization’s objectives and those of their clients. Royal Bank, at least in this case, chose a “we win-you lose” strategy, which is costing them at least one client (yours truly). The challenge for the organization is to find “win-win” scenarios where the clients are happy with to buy the products of an organization where they see value and the organization makes money.

Many brick and mortar companies learned this a while ago and took specific steps to ensure ethical compliance (at least relatively speaking) in the way they source and sell their products. Take, for example, Wall-Mart’s “roll-back prices” tag line. They found a way to align their bottom line objectives with those of their customers. It appears like financial organizations have a few things to learn from Wall-Mart, Costco, and many other goods re-sellers.

What Product Development Companies Can Learn from a Neighborhood Entrepreneur

I have been watching a local entrepreneur build his business from scratch over the past two years and I applaud him for doing all the right things to establish his company, which appears to be very successful so far.

He is a restaurateur, who set himself apart from a very crowded market in Toronto, Canada. Here are the things he has done over the course of two years:

Identify a Niche and Stick to It

He started with one single dish (smoked meat) with appropriate condiments. Nothing else! He did not copy other successful smoked meat delis, but developed his own style and flavor.

Develop Effective Partnerships

He started his business as an add-on to an existing pub. He served his signature dish while the pub served everything else. The partnership made sense when I first saw it and gave the entrepreneur a chance to start with a very small investment.

Test Your Product Early & Modify as Needed

In his early days, when he operated out of the pub, he would personally serve his dish and ask for patrons’ opinions on the food. He experimented with a few flavors and asked for feedback. He has always been friendly and easy-going. For the first few times, I did not even know that he was the main guy behind this. I thought he was the cook, who had a bit of idle time to chat with customers.

Move to Market at the Right Time

He opened his own deli, when the buzz started build about him and his dish. By that time, he had developed a level of recognition and support from the local community. In addition, he was featured in a few newspapers and magazines.

Stay True to Your Core Business

His deli shop continues to offer his great dish as the signature food. He carefully expanded his menu but kept it small. He continues to offer excellent and friendly service and comes out of the kitchen to chat with customers.

In case you are wondering, I am talking about Caplansky’s Deli (http://caplanskys.com) in the Little Italy neighborhood in Toronto. But, that’s not the point. The point is that Zane, the owner, did everything right in the book of product development. A lesson to learn from a local guy.

SnapIt – A Good Product: Easy to Use & Solves a Problem

Many people like to complain about products they use or talk about unmet needs. I am interested in hearing these complaints & needs. There is still a long path from identifying the needs to delivering a solution to the market but you got to start somewhere.

A good product I used in the past is called SnapIt (http://www.digeus.com/products/snapit/snapit_screen_capture_3_5.html), a screen capture tool. First, a disclaimer: I am not in software review business, nor intend to be. But, this is a tool that fits the two qualifiers in the title:

1. Easy to Use: This is a well-abused term. Nobody really knows what it means and developers roll their eyes when they hear it as a “requirement.” Without getting too technical, here is why I think this tool is easy to use. Installation was straightforward and I could start using it right after the installation ended. No manuals to read, “readme” files to check out, online communities to get tips from, so on so forth. These things may exist with SnapIt, but I don’t really care. To me, it is a tool that does something I need (will get to this in the next point) and does it in a way that made sense to me. Yes, fully subjective, so what?
2. Solves a Problem: I always hated the “Print Screen” button that ever existed on keyboards. It is just plain useless! And, I don’t want to capture my whole screen and try to crop out the area I need in yet another software. SnapIt does just that. It lets you pick whatever on your screen that you need, create a snapshot and done. I did not think it was a difficult thing to create a tool like that but it took many years until I saw something that I liked.

Yes, it is one small thing in life, but life gets better by taking care of things one at a time.

Consulting Tools – Pre-Packaged vs. Custom-Tailored

I am not sure if it is only me but I was tired of consulting firms offering their tools to me when I was in the corporate world. For the most part, I value the contributions of a good consultant. Heck, I am one of them now. However, the ones ticked me off are those who come in with their “tested” methodologies and try to force-fit your problems into their tools. I am talking about lean, six-sigma, so on so forth, which, in my mind, are big names for common-sense toolkits.

Let me recite one of my experiences: One of the companies I used to work at brought in a new CEO, who was expected to turn around the share price that had an undesirable trend. The new CEO was an ex-McKinsey guy. Being well-trained in the McKinsey-way, he immediately deployed a Lean-Sigma initiative across the corporation. The objective, as he put it, was to drive out waste and save money. Now, one of the problems is that the division I was at is a cutting-edge research and development company. Its products define the top-line. Research, that made this possible, and engineering, which turned lab experiments to products, relied on many processes and practices. At a superficial level, some of these practices and processes appeared to be wasteful and the Lean-Sigma teams jumped on them with sparkles of joy in their eyes and claimed early victories. The problem was two-fold:

1. If these practices were not observed, the main innovation artery of the company would be severed,
2. The “savings” were so-called “soft savings,” that is the Lean-Sigma teams saved the researchers’ and engineers’ time. Since these are salaried people, there were no real dollars saved. Nobody was let go.

Of course, the processes and practices were continued by staff, who knew better. Also, the “soft savings” subject was being abused by the Lean-Sigma team. The CEO noticed the abundant soft savings, which did not really contribute to his bottom line. Therefore, he corrected the course of the Lean-Sigma teams and asked them to go back to him with hard cold cash savings, and gave them a target. Guess what happened!

First, the target was never met.

Second, the attempts to save hard cash moved the Lean-Sigma teams towards manufacturing and procurement. Nothing related to R&D could get any attention, because all the best and the brightest were assigned to the Lean-Sigma teams. Some liked the idea but most grumbled and went along.

Long story short, the CEO is now gone. During the approximately five years of his tenure, the share price dropped to about 40% of the value from the days he took over.

The morale of the story: I am a firm believer of customizing the solution to the needs and realities of a company that seeks consulting help. When people ask me whether I have some tools that I have branded, I ask them to state their problem first. A tool is only useful when it fits the situation. I thought this was simple and common-sense. I have learned over many years that it is far from common-sense.

I guess this blog entry turned into a bit of a tirade. What do you think? Am I off here?