Saturday, September 22, 2007

Engineers know best - follow-up

A while back I wrote the post, Engineers know best. As a follow up to that post, it turns out I made the right decision. The engineer who had promised the completion of his tasks on time put in long hours and did in fact complete all of his work on time. This was the case of an engineer who wanted to complete his tasks and who knew the challenge ahead of him better than anyone else.

Similar to this common lesson is to listen when the engineer feels the assigned tasks cannot be completed in time. As a software engineer I was always able to complete my tasks on time-but the tasks were not always done right. When pushed to complete an unrealistic schedule, corners will get cut. These corners might not show on the surface, but under the hood the code might be an unmaintainable mess.

A quick YouTube video, “How developers fix bugs”, is a satirical explanation of how software developers can cut corners.



The lesson to learn here is an experienced engineer needs to be trusted when it comes to planning schedules. As a project manager we know project management, budgeting, resource management, customer requirements, and we might even have many years of engineering experience. But the engineer knows his or her skills, abilities, and the hidden coding obstacles he or she will need to overcome. Listen to your engineers and trust their recommendations. The success of your project’s success depends on it.

Wednesday, September 19, 2007

Getting Customer Buy-in for Innovative Technology

Many innovative technology creators experience trouble selling ideas for new software concepts or technologies to organizations that have solid operational processes. I find this especially true if the technology does not fit in with the organization’s current process even if the technology can help reduce costs, save time, and or increase quality.

To some, this seems like a chicken or egg thing. The organization’s current process does not match the use of the technology so they do not by into it, and the company will not change their current process because they do not have the tools needed to change their process. I see this as a misconception. Processes are created to gain efficiency and accuracy based on the resources, information, and time that constrains the organization. If a new technology comes along that changes these constraints, then the process needs to be flexible enough to become efficient and accurate given the flexibility in constraints that the new technology provides.

For example, consider the fictitious organization, Thinkmuch Inc. Thinkmuch is a logistics consulting company. Customers come to them for help on transporting large awkward items (such as houses and large boats) over long distances. Thinkmuch cannot afford to create detailed plans for transporting their customers’ items only to have the customer disagree with the methods and plans of transportation. So, Thinkmuch has come up with a process of two phases to create their plans. First they create high level plans and then get buy-in from the customer. They don’t waste time with many details on the first phase because if the customer doesn’t like the plan, the time creating the details of the plan is wasted. With Thinkmuch’s current resources, detailed planning takes weeks apposed to high level plans that only take hours to create.

Thinkmuch Inc. is now being presented with a technology called Processmuch. Processmuch allows Thinkmuch to enter in the dynamics and properties of the customer’s items as well as the items’ starting location and the desired ending location. Processmuch then takes into account Thinkmuch’s available resources, future weather conditions, the road and transportation systems that item might be transported in, etc. In fact, Processmuch processes all of the decisions that Thinkmuch does in both phases of planning. Using Processmuch the time to create the detailed plan (including the data entry and processing time) only takes one hour.

So does everyone at Thinkmuch see how Processmuch can help? Nope! Why? Because in the first phase, detailed planning is not currently done. The employees that do this phase see Processmuch as overkill and the employees who work on the second phase do not want to “waist time” entering in the dynamics and properties of the customer’s items. When the employees’ assessments of the technology find there way to the decision makers at Thinkmuch, the decision makers receive nothing but unfavorable reviews.

To prevent these situations, creators of innovative technology need to select their initial customers carefully and strategically. You need to select early adapters that understand the relationship their processes have with technology and the constraints that form them. Unfortunately, these early adapters do not usually have deep pockets and the non-early adapters (such as Thinkmuch), are usually the ones who have money to pay the higher prices. When selecting the early adapter you need to select ones that have visibility to the non-early adapters. The early adapter will prove the validity of your technology to the non-early adapter. The trick is finding the early adapter who has visibility to the premium paying customers.