Intrascope moved its blogs to Wordpress: http://intrascope.wordpress.com/

Folks,

I moved my blogs to Wordpress, please continue to follow my blogs at http://intrascope.wordpress.com.

Thank you.

Ferhan Bulca, Ph.D., P.Eng.
Principal
Intrascope Consulting
ferhan.bulca@intrascope.ca

Ensuring Software Quality Through Predictive Models

Ensuring high-quality software delivery continues to be an unsolved problem for many companies. Software development methodologies have evolved to match the needs of the fast-paced industry. However, good and reliable tools for effective decision-making with regards to when software is ready to be launched still do not exist.

Recently, I learned about a research in this area, which may change this situation. Over the past ten years, a group of academic researchers have been working on developing predictive models that analyze complex code, including code metrics as well as team (human) metrics. Their models very effectively predict which parts of the code is likely to be defective and unreliable. The research group published over 80 scientific articles in prestigious publications and extended their research to industry collaborators' code. Their research has attracted international interest, included that of IBM Canada and Microsoft Research.

Intrascope Consulting is now working with the research group to commercialize the analysis tools in order to extend the benefits to all software development organizations. As we do this, we are offering analysis services free of charge to organizations that are actively developing software. If you are interested in participating in our offering, please let me know: ferhan.bulca@intrascope.ca.

Please stay tuned for more updates on this topic in the coming months.

Knowledge-Based Product Development

I started hearing a relatively new term: Knowledge-based product development and wondered why it was creating a buzz. After all, it is a new name for an existing concept. Just like many other things, new terminology gives the impression to the naive that some silver bullet has just been invented and it will solve all problems known, in this case, in product development. Do I sound cynical? You bet! I am not the type of person who likes to rename existing things, concepts, methods, practices, whatever.

OK, enough ranting. The basis of knowledge-based product development is the same as systems thinking and systems engineering. See, for example, my blog entry titled "Implementing Systems Engineering in a Commercial Organization," dated November 23, 2009.

Knowledge-based practice advocates (rightly, in my opinion) an empowered product team making design and development choices based on a solid understanding of the customers' and stakeholders' needs. The opposite of this concept is a waterfall approach, which fell out of favor many years ago (again, for good reasons). So, why is there a need to rename and reincarnate an existing concept. I can think of two reasons, based on my experience:

1. Systems engineering has a reputation for being too formal, bureaucratic and top-heavy. While unfair, many commercial companies share this view due to their historic knowledge of systems engineering in the aerospace industry from the 1960s. Aerospace has come a long way since then but the opinions persist.
   
2. Systems engineering has a technical and old-school feel to it. In many cases, it is associated with hardware development only, which is a huge misconception.
   

The new term appears to successfully address these two areas. Knowledge-based product development has gained traction in software development and is not perceived as a heavy load. Even if it added nothing else (in fact it does, but that's for another blog article), it should get credit for breaking these misconceptions and opening the road for encouraging good and effective product development practices. In closing, here are, what I consider to be, the main principles of a successful product development organization, whatever one may choose to call it:

• Customer and stakeholder needs are clearly identified upfront,
  
• Customer and stakeholders are represented in the development team to address day-to-day decisions,
  
• Decision-making is done at the lowest possible level,
  
• Solutions are produced to address the highest level improvements (i.e., global optimization rather than local maximization),
  
• Accountability and responsibility is embedded in the development team,
  
• Team members have a clear understanding of their product and how it fits into the product portfolio of the organization,
  
• Product architecture is meaningful and well-structured. Both the decomposition and integration are logical and robust.
  

I hope you find this article helpful. I welcome your opinions and feedback on the topic. Please write to me at ferhan.bulca@intrascope.ca or comment here.

Product Architecture and How It Helps Save Time and Effort in R&D

"Product Architecture" is one of the most misunderstood concepts in product development. Let me first define what I mean by the term:

Product Architecture is a definition of the functional and structural building blocks of a product (software, hardware or service) and a description of the interactions among them.

In an earlier blog entry (dated June 25, 2008), I identified the four main components of a good architecture:
i) Functional architecture: what does the product and its sub-components do?
ii) Design architecture: what sub-components does the product have?
iii) A mapping of functions to sub-components: what is the function of each sub-assembly and component?
iv) Interfaces: Identification of each interface between the sub-components.

Note that I replaced the word "sub-assemblies" with "sub-components" to avoid hardware implications. The same is true whether your product is hardware, software, service or, in most case, a combination.

Anyway, let's get to the main topic of this blog entry: saving time and effort in R&D through good product architecture definition. Let me illustrate this through a case study. I was the main system-level product architect on a product aimed for the health science market. It consisted of hardware, software (both user-level and instrument controls), consumables, and service. Architecture development was a foreign concept at this company, which required both education & training in addition to the actual development of a sound product architecture.

The end result was a product architecture that captured the full complexity of the product portfolio, took into consideration future potential upgrades and improvements, allowed practical decomposition of tasks and simplified integration of the sub-components. And, it stood the test of time after more than eight years, by being a fundamental product description tool.

Putting the effort into a product architecture resulted in significant savings in the first and follow-up projects on the product platform:
1) Design effort for some sub-components were outsourced to subject-matter-expert companies. This resulted in higher-quality results without going through in-house learning for non-core competence areas,
2) Testing was done at lower levels and system-level testing was significantly reduced. For example, other instruments with similar complexity required 2-3 months of system-level testing while the product described here required 3 days (yes, days!) of system-level testing.
3) Last-minute changes could be implemented without triggered large-scale verification. All verification was limited to the changed components and their interfaces.
4) Design teams were smaller than other similar projects in the company. Each team focused on their sub-component and its interface functionality.
5) Concurrent development was effortless through interface emulators. The teams did not need to depend on the "other side" of the interface during development.
6) Follow-up projects were performed by much smaller teams compared to similar complexity upgrade projects in the same company. In some cases, upgrades and their testing was completed in less than half the time other projects required.

While it is almost impossible to accurately estimate the savings in the life of the product portfolio, here are a few numbers:
- The first project cost was approximately $4-million less than comparable projects in the same company.
- The follow up project cost was only 40% of what was originally estimated before the whole program started.
- The first project team, which developed the architecture, size was about 20% less than that of comparable projects.
- Follow-up project team size was significantly smaller.

I hope you find this posting helpful. I welcome your feedback and comments. You may reach me at ferhan.bulca@intrascope.ca.

The Missing Link in Innovation and Commercialization

The Globe and Mail article on commercializing research by Terrence Belford touches a few very important points. You may read the article at: Commercializing research: We've got the brains, now we need some brawn.

Terrence points to the missing link, when he quotes "...when it comes to university research we are among the top nations in the world but when it comes to commercializing that research we rank well below most industrial nations." He further quotes "Universities don't feel that [commercialization] is their job and industry is not willing to assume the risk and financial burden to take discoveries to the next stage — proof of concept, identifying potential applications and building prototypes."

Universities have established technology transfer offices to perform this task but my experience shows that they do not help bridge the gap. Instead, it typically adds to the burden and accomplishes very few results.

Having been through this "no man's land" a few times, I have learned first-hand that the expectations at technology transfer offices of universities and those of industrial partners are very different. The universities want to get the technology out of their hands too early for the liking of the industry. They mostly miss the fact that the transition from basic research to development is not a simple hand-over. It is a collaborative effort, where research continues to wrap up while commercial development ramps up. The overlapping activities and the investment (both effort and money) that goes with it appear to be in this no-man's land.

In fact, bridging the gap and turning more ideas to commercial successes are not that complicated. It requires the following activities, where both parties have to be involved and collaborate to achieve a successful result:
1) Technology expertise
2) Market definition
3) Product definition
4) Technology tweak (if necessary) to meet product definition
5) Development team building
6) Knowledge transfer from Research to Development team

When universities stop at step (1) and do not participate in the next steps, commercialization hits a major obstacle. Therefore, the only successful examples of commercialization appears to be when the technology developer takes a personal interest in commercialization and gets involved in the next steps. This is great if the inventor also has commercialization skills and interest in moving from research to becoming an entrepreneur. A more effective approach is to engage organizations that are designed to bridge the gap using a disciplined approach and proven practices.

I hope you find this posting helpful. I welcome your thoughts and feedback on the subject. If you are interested in commercialization services, please visit Intrascope Consulting.

Innovation in the Canadian Federal Budget

Canadian Federal Budget has been announced and there are hardly any surprises in it. It attempts to support Canada's economic recovery while trying to bring the deficit under control. In 2009, Canada followed the footsteps of the USA and pumped money into infrastructure projects. In 2010, the government takes a more sustainable approach and announces "cash for 'practical' research." There are a few noteworthy observations:
1) Research and development is one of the few areas where spending has increased over last year while most other areas remained the same or reduced,
2) There is an emphasis on health and applied research in it,
3) Manufacturing, aerospace, forestry and nuclear industries receive good sums of cash.

The biggest winners of the new focus on innovation will be Canadian colleges and universities, which will have access to new resources to commercialize their research. This is a boost to the technology transfer offices in universities, whose mandate is to find practical fields for new inventions. The additional challenge is that the government will want to show results for its investment and is likely to put time pressures to achieve its own goals before the next election. In addition, the caveat on the "practicality" of research will probably cast a shadow on basic researchers, who may not be bothered by the potential applications of their inventions.

Regardless, in my opinion, the Canadian Federal Budget's investment on innovation is the right step to help productivity and creativity in Canada. The industries selected for support are those Canada has a strong presence and is likely to succeed in the coming years and decades. Now, it is time to take ideas and commercialize them to help the recovery through new products, which capture markets. This will lead to manufacturing, marketing & sales, and service jobs that are desperately needed across the country.

I hope you find this article helpful. I welcome your comments and feedback. You may reach me at ferhan.bulca@intrascope.ca.

Lessons in Corporate Leadership - Culture Building

Training is one of the topics that receives serious lip service but little real support in many corporate environments. Research shows over and over that people rate "sense of achievement" and "meaningful work" very highly in their overall job satisfaction. Then, how do employers make the everyday tasks meaningful? How do they ensure that the tasks lead to successes and achievements? I will argue that training is a significant and important component of providing a work environment that supports job satisfaction.

Let me give you an example: All top-level executives were present in the room that was going to be the home for a number of new employees for the next couple of days. The company provided an onboarding training session to all (and, I mean all) of its office employees. The company was going through significant change and a large number of employees were being hired across its global locations. And, every few weeks, a training session would be set up for the new hires.

The sessions started with one of the top-level executives introducing the management team to the new employees and they would ask the new employees to introduce themselves to the rest of the class. The executives did not simply appear and disappear from the sessions. They were present a significant portion of the sessions, socializing with the employees during breaks and evenings.

The training sessions were seen as a way to introduce the company to the new hires, show them the culture being created and ensure that they participated in building that culture. It took serious commitment from the top and they demonstrated their commitment clearly and regularly.

The sessions had two major effects on the employees:
1) A coherent understanding of the vision of the executive management,
2) Belonging to a closely connected team and professional connections among new employees.

Needless to say, the morale and motivation of the newly hired employees were very high during and at the end of these training sessions. They returned to their offices across the globe and got to work.

I hope you find this posting helpful. I welcome your thoughts and comments on the topic.

Lessons in Corporate Leadership - Open Communications

Clear, honest, open communication... Everyone strongly stands behind the need for it in a corporate environment. In fact, in any environment. Then, why is it so difficult to do it properly and in a timely fashion?

Communication is a two-way process and it must have a purpose. I suggest taking the following steps in any communication:

1) Determine the purpose of the communication,
2) Identify the best method and environment for it,
3) Prepare the communication,
4) Deliver it,
5) Check results. If necessary, repeat from (1).

Here is an example, where open communication was seriously hampered. And, it is easy to see why.

It was the very first corporate-wide senior managers meeting, where attendance was solid. Many flew in from globally distributed locations because it was made very clear by the top guy that missing these meetings was not an option. "Very nice" I thought to myself. A CEO, who does not just deliver lip service but bites the bullet and brings all his senior staff together regularly.

Before the start of the meeting, there was a lot of hand-shaking, catching-up over morning coffee, old-timers and newcomers mixing and mingling. Anticipation about this meeting was particularly high because of the new direction the company was preparing to take in the coming months.

With this, the meeting time arrived and everyone took their chairs. The noise of the conversations muted a bit but continued. Then, the COO walked into the area in the middle of the U-shaped table and walked over to one particular director. What followed in the next few minutes killed all the chances for having a high-energy, high-participation discussion. The COO yelled and cursed (yes, using profanity) to the director for not doing something he and the president asked the director to do. The president joined the monologue (the director did not open his mouth). After about five minutes, which felt like hours, of yelling and cursing, they were done.

And, this was done to "encourage" sincere and open discussions on mistakes as well as successes.

I can only guess the purpose of the president and the COO in the above example. However, if it was to improve and make progress, it did not happen. I am not arguing that communication should be sugar-coated or distorted to protect the recipient. On the contrary, that would come across as insincere and inaccurate. Instead, use the five steps mentioned above and do it in a systematic manner.

I hope you find this article helpful and useful. I welcome comments and thoughts on this topic.

Lessons in Corporate Leadership - Delegation

Delegation comes with increased responsibility, as one’s job description shifts from “doing” to “getting it done.” While it is common knowledge that delegation is required in management, few perform it well. First, let’s review some of the basics of delegation.

Delegation is an act the supervisor does to get things done through others. Delegation does not change the ultimately responsible person for the task, i.e, the supervisor. Therefore, it requires trust between the delegator and the delegate. Further, it requires a clear understanding of the desired outcome. What happens between understanding the task and delivering the results is where things may get thorny. While the supervisor is responsible for the end-result, he willingly gives away the control over the methodology to achieve the end-result to his delegate.

Egan (Egan, 2005) describes the five steps of delegation as follows:
1) Define task,
2) Select delegate,
3) Communicate task,
4) Monitor progress,
5) Review results.

Now, let me share with you an experience I observed, where almost all of the above steps were violated.

"Wow!" exclaimed the president of the company. The words that followed showed his level of excitement and appreciation for the work that was being presented to him.

Earlier that month, he had asked one of his senior directors to find a place that would be the future corporate headquarters. He wanted to create a refined, sophisticated and elegant image for the company and the headquarters had to fit the image.

While the space we were touring looked prime, the location did not exactly fit what the president desired. We all knew this but were surprised by his articulate show of excitement and support. I thought to myself that economics had won over a trendy location in the city. The director showing off his find was proud and happy. So, he went on to finalize the deal and sign a long-term lease.

I learned about the president's real feelings on the way back to our interim headquarters. He hated the location and did not feel that the director was up to the job. He thought, the director did not understand the president's vision for the company and, therefore, had failed to find the right place.

Now, what is wrong with this story? Or, maybe I should ask, "what is right in it?" Basically, four out of five steps of proper delegation was violated.

The only step the president did correctly was to define the task. His senior circle knew his vision. However, he chose a delegate who was more concerned about the cost of the place and did not appreciate the president's no-holds-barred approach to the headquarters. Having chosen such a delegate, the president should have made his task clear to the director. Instead, he assumed that everyone in the organization knew and understood his vision. Therefore, no further communication was held between the president and the director.

Finally, the president failed to monitor the progress as the director continued on with his search. Although he made attempts to obtain feedback, the final one being the facility tour I mentioned above, the president chose not to do so.

The end result was a mistake that cost the company hundreds of thousands of dollars and the senior director his job.

How could it be avoided? Easily, in my opinion. I already shared my thoughts on how the president could have avoided a costly mistake on his part. The director, on the other hand, could have taken a few steps to better perform in the task:
1) Discuss the task with the president frequently and in specific terms. Discussing specifics engages both stakeholders and prompts real feedback.
2) Update the stakeholder in private before making a public display. It is much more likely to attract critical feedback in a private discussion, where specifics are discussed.
3) Request a final review of the results before committing to it.

I hope you find this article helpful and useful. I welcome comments and thoughts on this topic.

------------------------------------------------------------------------------------
Egan, B.D., 2005, "Delegate or Suffocate - the Art of Working Through Others," www.globalknowledge.com.

Teaching a Course on Product Development

Product development is a multi-disciplinary task. However, the skills universities teach typically are limited to the students' discipline area. In many cases, students graduate with little or no exposure to other disciplines and without any knowledge of how to operate in teams with different skills. My course idea was born to help fill this gap and introduce engineering students to the real-life experiences of product development.

I did some research on similar courses but I was surprised to find very few examples of such offerings. While a few courses exist, they are far from common.

With this, I approached my alma mater, where I received my M.Sc. degree, Bogazici University in Istanbul, Turkey, and proposed to deliver a course on product development. I received a very warm welcome and my course is approved for the summer term.

Now, the real work starts on my part. That is, preparation of the course materials, textbook selection, case studies & guest speakers, so on so forth. I am both excited and scared of the upcoming summer. My excitement comes from the opportunity to share my learnings of the years I spent in product development. I am scared of the challenges in keeping the topic interesting and engaging during a summer term.

I am looking for any input from current educators. All advice and suggestions are welcome to make the course more effective.

Thanks.