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
Monday, April 12, 2010
Wednesday, March 31, 2010
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.
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.
Tuesday, March 16, 2010
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:
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:
- 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.
- 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.
- 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.
Friday, March 12, 2010
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:
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.
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.
Tuesday, March 9, 2010
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.
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.
Friday, March 5, 2010
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.
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.
Saturday, January 30, 2010
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.
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.
Subscribe to:
Posts (Atom)
