Immigrant engineers in the Canadian job market

When I was invited to attend a "speed mentoring" session organized by ACCES Employment, I was a bit skeptical. I have never been a believer in those speed-whatevers. They don't sound natural to me.

I expressed my concern and the organizers explained the purpose as "to find a connection between the mentees and the mentors so that they can follow up later." Now, that made sense.

For those who don't know, let me explain what ACCES Employment ((www.accesemployment.ca) does. It is an agency that helps new immigrants to integrate into the Canadian job market. The particular session I was invited to was geared towards engineers, aiming to introduce them with those of us who have been on the hiring side and provide them with guidance to get their first Canadian jobs.

So, I went to the session and am I glad that I did! Upon entering the modest office of ACCES, I was greeted by the organizer and a number of hopeful faces. The organizer escorted me to the room where the session would be held. A couple of other mentors who arrived earlier were already there, so we chatted a bit. Then, the mentees arrived, all dressed to impress, resumes in hand, some a bit shy, others more eager to strike a conversation. After brief introductions of ourselves, we started the mentoring session where each mentee spends about five minutes with each mentor. When the time is up, they rotate. I guess you get the picture.

To say that I was impressed by the quality and caliber of the engineers I met at the session would be an understatement. In addition to undergraduate degrees in engineering, they had advanced degrees in engineering or business. Since arriving in Canada, they learned programming and other computer skills. Other than one fresh graduate, they were experienced in their fields. And, in spite of a very slow job market, their attitude was positive and forward-looking.

I hope the answers we provided were helpful to them. They have a lot to contribute to the Canadian society when they have the chance.

Implementing Systems Engineering in a Commercial Organization

Systems engineering was born in the aerospace industry from the need to coordinate the technical complexities of large, multi-national programs. The principles and practices of the discipline gained widespread recognition and systems engineering became a fundamental component of all programs in the aerospace industry in the second half of the 20th century.

These principles and practices of systems engineering has been attracting attention at commercial companies in the past decade. Most of these companies agree that they do not need the level of complexity of systems engineering utilized by the aerospace industry and attempt to define a model that would work in their organizations. I led a similar initiative at a company which develops and manufactures laboratory instruments that are primarily used in the pharmaceutical companies.

The mandate of the initiative was as to improve the quality and discipline of product development through implementation of systems engineering practices and principles. Main pain points in the organization were as follows:

• Interactions between Marketing, Research, engineering and manufacturing were disfunctional, 
• Engineering typically did not know which features were critical for the success of the product,
• Documentation of products was minimal and, mostly, unusable, 
• The products were complex. Interactions within a product's subsystems were not understood, making lower-level testing impossible. 

 We took the following steps to implement a systems-based product development structure in the organization:

1. Understand the Organizational Goals and Define an Appropriate Solution
   This is the most difficult but crucial step before jumping into "action." We took the time to interview stakeholders, from senior executives to those in product development, to fully understand how the organization operated and where it wanted to go. This step helped with engaging relevant parties early to contribute to the definition of the solution and build up support for the initiative.
   
   This is the step where the magnitude and scope of the initiative is clarified. In order to implement a truly systemic product development capability, it is necessary to address organizational and management structures, skills in the organization and those outside it, tools used in development and product development strategy of the organization. In this initiative, we chose "go big, think fast, act quickly" approach.
   
   The biggest challenge at this stage is to overcome the desire to do something quickly and show quick results to the sponsors of the program. Therefore, frequent and clear communication, is crucial at this early stage of the initiative.
   
   
2. Choose and Engage Partners
   Once the desired end-result was defined and the path to it was planned, we sought help for specific areas of the implementation. For example, we decided to engage an outside company for the training program, which was going to target over 200 people in the organization. Similarly, we decided to bring in various systems engineering software tools and engaged the selected vendor at the start of the initiative.
   
   The value of engaging partners early in the initiative is very high. First, they have seen similar implementations at other places and can contribute to your program with suggestions and comments. Second, they know their tools and materials and can help you tailor your implementation to best utilize their products.
   
   Our program significantly benefited from the early engagement of partners. For example, our tool implementation went without a glitch and acceptance among users was almost instantaneous. Quite an achievement for a enterprise-level software implementation.
   
   
3. Pilot Program
   Any large implementation, however well thought out, will stumble on a few unexpected issues. It is best to detect and correct them on a pilot project. For this implementation, we chose two projects: a software-only project and a hardware/software development project. We provided just-in-time training to the pilot project teams and instructed them to apply the systems practices in their projects.
   
   The pilot projects provided valuable feedback to the implementation team. Without the pilot projects, the success of the implementation would have been significantly reduced and probably could have led to a failure. Some great ideas came out of the pilot program which were implemented. Some other complaints were addressed through training and tool improvements.
   
   
4. Deployment and Training
   Deployment of the new practices and principles was done in the following way:
   
   • Projects that were beyond a certain phase were allowed to continue with previous methodologies. These project teams were included in the basic training program and most chose to adapt some of the newly introduced practices.
   • All other projects were instructed to switch over to a systems-based methodology. Each project team received extensive training in the basics of the new methodologies as well as a tailored training to help with the switch. Project managers were asked to evaluate the impact, if any, of the switch and update their project plans accordingly.
     
   
   
5. Support and Improvements
   The end of the implementation initiative is the start of a new stage in the organization. The final task of the implementation team was to identify an "owner" to the deliverables of the initiative, i.e., processes, tools and the training program. This owner was the single point of contact to provide support and training as required. Additionally, the owner was responsible for collecting feedback from project teams and improving the processes, tools and the training program accordingly. 

 This results of this initiative stood the test of time and has been in a continuous improvement stage since its completion in 2007. The practice continued to grow and renew itself as the organization grew through acquisitions, moved its manufacturing to overseas, and the staff in the organization moved in and out of the organization.

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

Is Your Product Development Strategy Increasing Your Time-to-Market?

It is my experience that many companies have relatively relaxed product development strategies. Most declare lofty goals like "delight the customers" or "be the leader in performance" but these statements lack clarity for the development teams that are supposed to help the organizations meet their business goals.

Product development performance and effectiveness requires clarity in two areas:

1. New product development (NPD) strategy,
2. Product portfolio strategy.

Let me explain what these two concepts are and how they are different.

NPD Strategy is the way an organization introduces new products to its target markets. This is the "how," and it should lay out, in clear detail, how the organization handles all the tasks and activities related to product development. Examples of NPD strategies are development through mergers and acquisitions, technology partnerships, or in-house research and development.

Product Portfolio Strategy is the "what," which lays out what the company is offering to its target markets over time. It contains life-cycle of each product, from introduction to market till removal from use. Examples of product portfolio strategies are relevant product families, product platforms for different markets, legacy compatibility (or not), product and service packages.

There are two ways these strategies affect your time-to-market:

1. The content of the strategies: For example, if your product portfolio strategy involves inter-dependent products, development teams will have to ensure that a reasonable combination is tested before launch, significantly adding to the development time. Similarly, if your NPD strategy is based on in-house development, your teams may need to acquire new skills for a new product line.
2. The clarity of the strategies: Lack of clarity leads to interpretations and filling the blanks. As expected, none of these will resemble the intent of the organization and will differ even within the development teams. As a result, each team member or sub-group will work to a different objective, resulting in frustration, conflicts and significant delays in delivery. 

In conclusion, organizations need to pay attention to articulating two product development strategies clearly and thoroughly. Further, these strategies need to be regularly communicated, reviewed and updated.

I hope you find this posting helpful. I invite comments and feedback on my posting. You may reach me by writing to ferhan.bulca@intrascope.ca.

Start Your Product Development with Price

Yes, it is a great idea! And, your research shows that customers are willing to part with their hard-earned cash for your next product. Provided, of course, your price fits within the perceived value of the product. You are convinced your team can develop it with a reasonable profit margin. You give the "go ahead" to the team, they work diligently and, voila, the product is ready. Next, the suppliers' final quotes come for production runs. Opps, now your product is too expensive to produce, eating away all the profits you accounted for. What happened here?

Is this scenario your "regular" product development? It should not be. It is very possible to meet cost targets with a level of discipline and diligent enforcement of the target price during development. Here are the basic steps towards eliminating product cost surprises:

1. Determine your target selling price BEFORE the start of product development.
   It is difficult to set a price to a yet-to-be-developed product but this is where the strength of your market research team shows. At this stage, there are many assumptions around the target price, record them. Derive from it the target cost for the development team to meet.
   
2. Make the target cost a requirement for the development team.
   The target cost and the assumptions for it need to be visible and transparent for the development team. Identify an owner, who monitors the estimated cost of as-designed product during development.
   
3. Make product cost a component of regular design reviews.
   Estimated cost and the assumptions need to be reviewed regularly. Treat any indicators for creeping cost seriously and immediately. Do not allow "it will come down when we start producing in quantity" to be an excuse for high-cost designs to get by.
   
4. Feedback to design team the actual cost of product after development is complete.
   It is educational for the design team to know the actual cost of their design when it hits production. Make it a point to gather the design team after the product is in the market and compare the cost estimations from design reviews to the actuals.
   

These simple and effective steps were successfully implemented in a number of development projects I managed or oversaw. While the steps are simple, just like everything else, the devil is in the details. I would be more than happy to help you with your product development needs and tailor solutions to meet your objectives.

I hope you find this posting helpful. I invite comments and feedback on my posting. You may reach me by writing to ferhan.bulca@intrascope.ca.

Necessary But Not Sufficient

During these tough times, many employees have observed their companies taking very difficult decisions. These decisions helped some and were not enough to keep afloat some others. I experienced the latter, and unfortunately observed a once-profitable company go into bankruptcy protection.

This sounds like one of many stories we are hearing today. The situation I experienced is different in one major way: The company was a business experiment to apply a theory. Well, it did not work in the end but the path to the end was interesting and enlightening, if I may say so.

The CEO, President and the Board of the company strongly believed in "the combination of clever, committed people working together with a powerful approach could achieve any goal." And, they either hired accomplished people or re-positioned those already in the company to significant roles. They explained, in excruciating detail, the methodology to apply and tools to use. People were committed to making the company successful.

What went wrong then? Some accuse the economic downturn, I beg to differ. Clever and accomplished people, thrown together and given tools, is not sufficient to achieve a goal. This is good leadership; place capable people to effective roles, give them the tools and show them the vision. It is necessary but not sufficient by itself.

The path to success is full with obstacles, detours and misconceptions. Good managerial skills and operational savvy is also necessary to navigate through ever-changing conditions, personality issues and communication problems. In my opinion, that is what caused the company meet its unfortunate end.

In summary, creating a vision and setting a goal is only a beginning to a business journey. Success depends on the capability to take the team to the goal, one day at a time, through good management.

I hope you find this posting helpful. I invite comments and feedback on my posting. You may reach me by writing to ferhan.bulca@intrascope.ca.

Change Management Fundamentals

There is a common myth out there: "people don't like change!" I cannot disagree more. If people did not like change, why do they try a new food or a new restaurant? Why do they travel to see new places? Why do they meet new people and make friends? You got the idea...

Change is in our everyday life and we internalize it. Then, where does the perceived dislike for change come from, especially in corporate environments?

You must have heard it before that people would embrace change if they see a tangible and substantial benefit in the change. So, the first test for a change initiative is in the following two points:

1. Do the leaders sufficiently and effectively communicate the purpose, methodology and expected end results to their staff?
   
2. Do the staff understand and provide feedback on the initiative?

The first point, communicating to the personnel, is typically well-understood. Almost everyone who embarks on a change initiative does it, with varying degrees of effectiveness. The second point, however, does not get the attention it requires.

Let me give you two examples from my recent past, one of them successful, the other not.

In one case, where the objective was to improve engineering efficiency through the selection and installation of company-wide CAD tools, both points were used. The leader took the time to work the details of the plan with those whose daily practices would be affected by the end result of the initiative. The change leader gave autonomy to a few motivated employees who took it on themselves to achieve the objectives. The leader allowed modifications to the original action plan, but monitored it closely to ensure that the underlying goals were not forgotten. Staff and implementation team enthusiastically provided feedback and comments on the actions, thereby improving their chances for success. The end result was a fast and effective implementation of CAD tools, efficient training of the staff and effortless adoption of the new tools across the organization.

In another case, where the objective was to harmonize the sales team under a new set of operational rules, the second point was ignored. Those who spoke up and offered opinions were labeled as "resistors" or "saboteurs." Change leaders weighed heavily and, usually, publicly on those who criticized the actions. In the leaders' mind, they knew the right actions and they had explained them to the team. Any other opinion must be coming from a mindset of resistance to change. The end result was a disorganized and demotivated sales team, which led to a significant drop in sales.

I hope you find this posting helpful. I am always curious to hear your comments and feedback on my posting. You may reach me by writing to ferhan.bulca@intrascope.ca.

Ready for a better economy?

If you are an executive or middle-manager, responsible for R&D or product development, chances are you have been fighting with budget and personnel cuts, low demand for your products, low morale and an uncertain future. OK, we are all on the same boat and we all share the pain during these difficult times. So, how are you spending your time and energy during this time? If, like many, you are focused on saving the day, getting by with what you've got, then, you are losing valuable opportunity to position your team and company for the better days to come.

Let me tell you my story: I am responsible for New Product Development (NPD) at a company, which is significantly battered by the economic downturn. In response, I led my team to develop a NPD plan for 2009, which focused on three main strategic areas:
1) Consolidate and simplify product offerings. Enrich quality and features without increasing cost.
2) Increase the value for the customers. Offer relevant products within a portfolio. Develop complementary products that can be "bundled" as a full solution.
3) Identify the "next big thing" and start working on it.

The goal of the first two areas is to increase income in the short term while establishing a solid product foundation. Dedicating a group of R&D resources into these two areas enabled the company to deliver "more" to its customers. Product improvements and consolidations typically do not require the resources that would be necessary for "green field" development projects.

The third area is forward-looking. This activity determines our next steps and our next investments.

This type of activities are mostly postponed in tough economic conditions due to many legitimate reasons. Some of the reasons are staff shortage, inability to make investments, too many immediate issues, so on so forth. In reality, forward-looking activities do not need to take much resources. In addition, they have a positive impact on the overall morale of staff, even if they are not directly involved in them.

I hope you find this posting helpful. I am always curious to hear your comments and feedback on my posting. You may reach me by writing to ferhan.bulca@intrascope.ca.