Blog

My Career Part 2


Career; of Motorcycles and Trucks

This blog continues from my last post describing the first part of my career.  We continue with the tire pressure monitoring system.  In those days, and for many years before that, my preferred form of transport was motorcycle.  I had an accident a few years before taking this job that broke some bones in my wrist (not my first nor last set of broken bones), in fact I got the bike fixed and was riding it through the winter with my right hand in a cast, and with multiple socks on to keep my hand warm.  I should mention that my preferred transportation was motorcycle, at least in part, because it was my only source of transportation.  Eventually, my fourth job before my professional career started, the manager of the U-Haul at which I worked during my undergraduate education came across a wonderful, and old, Toyota station wagon complete with the fake wood siding, … Continue reading


My Career Part 1


My Career

I have been very fortunate in my career, and that really means very lucky.  Upon graduating from the University of North Carolina at Charlotte, I had two job offers after sending my resume to more than 100 companies.  That is not a very good yield, but it would be good enough.  I selected the smaller company, but I selected that company because they created new things.  The company I started at developed embedded industrial control systems.  It also turns out the people with which I would be fortunate enough to work, were very friendly, and as I would say, were a hoot to be around.  Some of my other blog posts describes shenanigans.  To this day we still have secret words, that mean something to us but nothing to anybody else (R4).

What drives me

My interest or objective has never been one thing when it comes to product development.  In the beginning, I was interested in … Continue reading


Project Organization Structure


If you have been a project manager for any time at all, you probably have experienced competing demands from the sponsors for the project.  The sponsor is the person(s) who drive the scope of the project in conventional projects.  In some instances, the project manager may find that there are in fact multiple sponsors and the respective priorities of those sponsors may be at odds.  This is not the only difficulty to which the project manager must respond.

From the CHAOS study by the Standish Group, on project failures and success factors, we find the results below. This study analyzed 23,000 projects in 1998[i], of the factors that enable project success and failure.

Success Factor Influence User involvement 20 Executive support 15 Clear business objectives 15 Experienced project manager 15 Small milestones 10

 

A list of the top 5 factors from this study, demonstrate that importance of the interface between the project, the executives that are supporting … Continue reading


Value, Scope and Change Requests


Value, Scope and Change Requests

Change requests are part of any development project.  Change requests are sometimes necessary as we learn by building and doing the work.   In my experience, change requests often are born from requirements we thought we understood, only to learn by working with the product or system that we really did not have enough understanding to be able to record this in the form of specifications.  We think we are making things better when we spend an abundance of time documenting the requirements, at least those requirements about which there is uncertainty. That is not to say this is not a worthwhile endeavor, we have been in product development long enough to know there are downsides to delivering a product that has no associated documentation.  The testing and manufacturing portions of the work will make use of these requirements documentation and the errant or lack of documentation makes the work of these areas and more difficult … Continue reading


Value Proposition


Value

Business is predicated on providing value to the customer, but it does not end there. The business itself needs to see value in the work, so this is really a value chain that is only as strong as the weakest link.  If the value to the customer is too low or not existing, no customers will purchase the product.  If the value to the business from the product is too low, there will be no investment

What is value

Value is the difference between the utility received and the cost for things.

Value = Utility – Cost

Value = Benefit – Cost

The utility may be customer dependent, but this must be understood, as this will drive the subsequent work. Not knowing what the customer values, clouds how we approach the work.  We will write more about the conundrum later.  It suffices to say no value to the customer means no value to the business, … Continue reading


What works: team participation


The team

My first job out of university was with a small product development and manufacturing company. The company developed their own embedded products for sale all over the world.  I do not know how this collection of technicians and engineers ended up as a tight or as close when it came to work.  The group was a collection of characters. The other electrical engineer, we will call Flicky (we had secret names for each of the team members). There was one technician we referred to occasionally as IR because of the unfortunate anagram is name made.  There was a mechanical designer we referred to as BWI, I will explain that later.  There was another assembler / technician we referred to as Wal.

Games with the Team

When it came to the electrical or embedded product idea generation and development, I can recall a game we played.  We would read the specifications together, asking questions where we could of the sales … Continue reading


What does not work – Queuing Theory


Queuing Theory

Queuing theory is the study of waiting lines and is associated with business in determining resources needed to achieve service business throughput objectives, but it does not just apply to services and material handling.

Queuing Theory and Billable Hours

I have worked at companies that had a target for billable hours, that well in the 90%. That is, 90% or more of the hours the employee worked, had to be assigned to specific project work. The organization treated the time an employee was at work and available to work on specific projects, at nearly 100%, so for example, in a 40-hour work week, it was expected that 36 hours or greater were dedicated to specific project activities.  This was recorded in the project schedule.

Queuing Theory and Product Development

The impact of queues on product development and knowledge management in general is explained well in this Harvard Business Review article a snippet of which is found below:Continue reading


Subscribe to our Newsletter

Subscribe to our Newsletter
Name
Email *
Single Sign On provided by vBSSO