A Blackberry Icon "picture" is Only Worth 1,000 Words If You Know What it Means!

An icon that showed up on my Blackberry Storm that I couldn't figure out.  That's bad design.  Icons should epitomize the saying that "a picture is worth a thousand words".  They should generate immediate meaning, save space and ideally, be attractive. 

Not only was the icon cryptic but Blackberry's user manual and web site provided no information about it.  I Google'd the issue and all I found were 25 other postings asking the same question I had.  There was no Blackberry icon glossary to be found.

I called Blackberry and was told that only by paying for "professional service" could my question be directly answered by them.  The agent did say she would connect me with my carrier, Verizon, who could answer the question at no cost, and if they didn't know, they were allowed to call Blackberry at no cost.  Go figure and please transfer me.

After describing the icon issue to Verizon, I put the phone on speaker and did other work while two people looked at the user manual and Blackberry web site only to report 10 minutes later that they were escalating this to the next level of support.  Fine...back to work.  The next level of support came on the line and asked if I had any 3rd party software on the phone as that might be the source of my unknown icon.  Yes I did, particularly since Blackberry, Android and every phone operating system is trying to catch up with Apple's by providing apps.

After opening Blackberry's own app 'Blackberry App World,' it turns out that the mystery icon tells me that Blackberry App World has updates for apps I downloaded from App World.  In other words, it's Blackberry's own icon that pops up but they can't tell me what it is unless I pay for "professional support".  Go figure as you check out iPhone pricing.

The customer experience was bizarre.  But equally important is how well intended but incomplete design can  harm customer experience.

Filed under  //  Blackberry   customer experience   Design Thinking   Tufte  
Comments (0)
Posted 7 days ago

A Suggestion for Comcast: Support Your Service Technicians!

 

I recently decide to switch separate video-internet-phone providers to Comcast because the phone-internet-cable bundle is significantly cheaper.  Comcast did a good job of setting up the appointment and their service tech, Al,  was on-time and addressed complexities in our home intelligently.  He left me his cell number and asked that I call should I have any problems.  Up to this point, very good customer experience. 

After returning from dinner, we turned on the Olympics and there was no sound.  It was 9:30 PM and sheepishly I called Al's cell but heck, if he didn’t want to be bothered, he could tell me or the call would just go to voice mail; which it did.

I next called the Comcast 800 number.  It took fifteen minutes for the rep to walk me through a volume fix.  Moments later the video went out.  Another fifteen minute call fixed that.  After that, the DVR cycled itself on and off several times.  At this point, I was wondering why did I do this?  BTW, I noticed the DVR was not new; most likely pulled out of previous customer.

On my third call to Comcast, the rep told me that the DVR/receiver box was likely at fault and I should bring it in to their service center.  Bring it in?  You’ve got to be kidding me!  This is a new and flawed install and I’m not about to take at least two hours to do that.  He then tried to convince me saying that techs don’t have control over what’s loaded on their truck so they might just bring another DVR out that’s also been used.  Plus, there’s no way he could contact them directly to insure a new or fully tested unit was provided.  I asked what if this was Brian Robert’s home, CEO of Comcast?  Would he get the same answer?  Another stiff arm led me to ask for a supervisor.

When I asked the supervisor why they wouldn't roll a truck to fix this, he said “I didn’t say that.”  True, the rep did and I just thought they worked together!  He said the best he could do was send a truck in three days.  One tires of these battles so I said fine wondering if I should switch back to DirecTV since I still had their receiver.

The next morning I called Al who did the install and left a message.  Hopefully it was early enough so he could grab a replacement, hopefully new, before he set out.  In twenty minutes I had a call back.  He had a new receiver and would be out that morning.  He came and hopefully, we’ll have no more problems. 

Here’s the kicker.  Al was great and offered his number to me.  I don’t know if that’s company policy or just Al’s good work ethic but it should be policy and supported by the 800 number service center.  Give scheduling discretion and accountability for customer experience to the local tech centers, particularly when it’s a new install. 

The first contact with a service is a classic “moment of truth” and while Al gets high marks, the Comcast 800 number understandably can’t schedule other than by remote calendar with a much longer lead time.  It puts the 800 number people in a bind because who’s going to be happy with the response?  Have installers give their number, or a local hotline if privacy is a concern, that at the local tech center.

Al’s done a diving catch for Comcast while the service center just took a dive.     

Filed under  //  customer experience  
Comments (0)
Posted 22 days ago

Rip Van Winkle Time: SAP Claims Reorg Will Restore Trust, Speed & Innovation

An Information Week article quotes SAP co-founder and former CEO Hasso Plattner that SAP is heading for “massive changes” to change the company’s culture and drive innovation.  What’s the change?  “We will have fewer hierarchy levels, we will have more agile project teams with a flat structure, and we are ready for critical decisions."

Hello?  The six fundamental steps for consistently improving speed were described in Fast Cycle Time (Free Press) over ten years ago.  They are:

1.       Clearly define what customers value and eliminate work that does not add value

2.       Align purpose, strategy and structure for speed

3.       Use a flat, multi-functional team-based structure

4.       Innovate process regular to pick up speed

5.       Measure speed using predictive as well as results measures

6.       Accelerate learning with hardwired feedback/action requirements

What is fascinating is how easily companies lose the recipe.  Our experience is that too many competitors pay lip service to steps 4-6.  Executives are quick to monitor schedule slips but that doesn’t tell you what caused the slip.  We know that design changes, multiple architectures (product and process) and capability gaps all slow innovation yet few companies watch these consistently.  The military that defends our country depends on “after action reviews” yet few companies regularly conduct in depth “post mortems” of recently completed projects.  What does an in depth review look like?

First, it involves the key team members.  This could be as many as 10 people in a small project to 30 in a large one.  We want the key players from every function together for three reasons.  First, they have the tacit as well as explicit knowledge of what actually happened.  All too often the most impactful barriers are subtle cultural traits that repeat across several projects.  Without getting the full story vs. “just the facts” you don’t have enough to design a real change.

Second, most delays of consequence happen at the margin between functions.  By having all present, you can have serious engagement between those responsible regarding root cause and potential solutions.  This is particularly true for the early concept and definition phases.  Unnecessary specifications iterations scrub speed.   We’ve also found situations where the spec was set far too early which essentially sets it up for failure.

Third, unless the people who lead teams change their behaviors, speed will not improve.  Actively engaging in a retrospective look activates energy for change as no one likes making the same mistake twice.  Consider the alternative that too many use.  They get two to four people together and spend a couple of hours identifying the “lessons learned” which is then distributed or put on a server.  Do you honestly think you’ll get much traction by having others read a report written by someone else?  If you want to change a person’s behavior, you need to engage them in defining the changes.  We’ve used a retrospective mapping process that in 3.5 hours, details what worked, what didn’t and prioritizes improvement opportunities. 

That 3.5 is far more cost effective and insightful than the cost and pain of SAP’s massive changes, invest consistently and your speed will continue to increase.

Comments (0)
Posted 1 month ago

Strategy 5: Purge the Old to Achieve Critical Mass

Here’s the last of five strategies for accelerating change efforts.  The complete paper is also available at http://bit.ly/9lpQUx

 Our fastest implementations follow a very different rhythm than slower ones.  Fast implementations start crisply with a full, cross-functional group of experienced leaders that operate in a semi-stealth mode for the first couple of weeks.  With the exception of a few external probes to test ideas and assumptions, they quietly outline the effort’s boundaries, critical resource requirements and sketch a draft change strategy that defines the sequence of major steps, potential obstacles and knowledge gaps.  Several of their predictions will be wrong, but the process of discussing the unexpected early positions them to handle inevitable surprises better. 

Slow implementations start with broader representation, take twice as long to get staffed and usually start with a public launch event that inevitably sets expectations higher than is helpful.  Following the “define it before you design it” school; slow implementers invest much more time in creating a detailed change specification and implementation plan.  Fast implementers define 3-5 critical endpoints and then rely on the nodes to flesh out the rest of the plan as they proceed.  The final change definition emerges later in the faster efforts but progress towards it is quicker and engages more energy and talent along the way. 

When they leave stealth mode, the fast implementers accelerate briskly by calling on their personal networks to establish the initial network nodes.  In contrast, the slower teams follow a more democratic process that uses broader criteria and takes considerably longer to reach a reasonable operating rhythm. 

Surprises and obstacles represent moments of trust that are watched by folks on the sidelines with great interest.  Fast implementers savor major obstacles as opportunities for sending symbolic messages.  Having anticipated obstacles and knowledge gaps early, fast implementations swarm major obstacles with resources and force as they appear.  Slow implementations treat the same issues as larger problems but with less regard for their symbolic value. 

For example, Fast Cycle Time implementations invariably have to confront “zombie” projects that have a strong emotional following, generate small returns yet consume significant resources.  When the broader community sees one of these living dead get a stake through its heart it accelerates momentum towards critical mass.

As the size of the effort expands, fast teams establish a tactical communication and prioritization forum to stay focused as they accelerate to critical mass.  Often divided into two parts, the first is an open meeting that sets the marching orders for the next week.  Attendance is large, real and virtual, with a strong norm that limits participation to those with highest relevance.  Ad-hoc post-meeting dialogues and instant messaging fill in the blanks left by the limited participation norms.  The second part is limited to center and edge leaders.  Their focus is handling interdependencies and insuring conflicts don’t linger.

As the tempo builds, fast implementers keep reaching forward and worry far less about those who fall off the back.  This requires a deft touch as some will always be left behind but unless they have showstopper potential, the fast teams keep raising the pace.  Slower teams tend to worry more about who’s not on board than who is.

As momentum reaches critical mass, our fastest examples accelerate by deliberately purging the old approach.  In product development there’s always a fair amount of chaos when some projects use the new model while legacy efforts hang with the old.  As soon as the new approach is robust enough to support most of the workload, fast teams escalate dismantling the old.  Removing the alternative gets them across no-man’s land quicker.

Conclusion

This piece was stimulated by a partner in a buy-out firm.  He takes businesses that are not achieving their potential and transforms them from good to great.  Just as our clients challenged us when implementing Fast Cycle Time to do it faster, his investors are constantly challenging him to shorten the time this takes. 

His challenge is not unique.  From the President of the United States to nearly every serious competitor, those who can change faster have a better chance of winning.  As much as there is a great deal written about how to manage change efforts, far less tells leaders how to speed it up.  The critical mass framework and five supporting strategies are based on our experience implementing Fast Cycle Time at companies including Ford, Procter & Gamble, and Hewlett-Packard.  They helped them get faster, faster.

Comments (0)
Posted 1 month ago

Strategy 4: Compel Network Growth Supported by New Citizenship Norms

Here’s our third of five strategies for accelerating change efforts.  Tomorrow  , we will publish the final strategy.  The complete paper is also available at http://bit.ly/9lpQUx.  See previous for the model’s introduction and strategy 1-3.

The network strategy moves as fast as nodes can subdivide or establish new ones. Splitting nodes, leverages the energy and talent of those already committed to reach out to new players.  Each time a node sub-divides, it spreads success stories and relevant insights that are hard to communicate except through personal contact.  This requires constantly shifting people, power and assets to the change’s forward edge. 

Using a network building change strategy requires a different organization model than a traditional centrally driven approach.  We describe it as a “Center-Edge” model.  The center owns defining the initial change objective, what’s in and what’s out of play, helps access resources, and facilitates alignment between the nodes and interfaces with “non-changing” elements including top management.  Unlike a hierarchy where power increases as you rise, the network center’s role is limited.  The bulk of the resources, change work and decisions occur at and between the edges.  Therefore, the edge has to redefine citizenship accountabilities that balance the limits put on the center.  

The alternative citizenship model provides a common substrate of expectations that raises citizen accountability higher than hierarchical models.  It is the quid pro quo for shifting power to the edge.  Network members and node leaders are responsible for initiating direct interaction with other nodes in contrast to a hierarchy which channels information and power through the center.   Unlike hierarchies where decision making authority implicitly fosters dependence, networks require the nodes to operate interdependently.  This requires transparent, two-way communication tools combined with better negotiation skills since “bumping up” decisions is a last resort option.  To make this work, change leaders have to push nodes to directly link and resolve issues.  Unless leaders put time into setting these new citizenship norms, the long heritage of traditional will transform the network’s potential into dysfunctional sprawl. 

 

Center-Edge

Hierarchy

Linkage to other groups, systems and resources in the change effort

Individuals are responsible for ongoing outreach as well as importing ideas, tools, and outcomes in pursuit of the change and in line with boundaries set by the center

Individuals are responsible for executing their defined roles & responsibilities and keeping central change leaders informed of progress

Responsibility for expanding change effort

Individuals are responsible for recruitment, change experiments and sharing with other nodes and center

Individuals operate within assigned tasks and roles

Decision making

Most decisions are made at the edges, driven by evidence and negotiation facilitated by the center

A steering committee is the primary decision forum to which sub groups report

Resources

Responsible for identifying and recruiting resources within and across nodes

Responsible for identifying resource requirements; recruit as directed

Conflict Resolution

Default: conflicts are owned at the edge.  Center insures critical conflicts are, addressed and acts on an exception basis

Conflicts are owned within local limits and then escalated to next level or steering committee

 

We stress two metrics to help keep edge citizens focused on building critical mass.  We track by name everyone that has participated in the change effort.  This guides recruitment and facilitates recognition for contributions which further drives more recruitment.  Second, we measure progress to goals using the maxim:  “every inch a victory”.  People don’t see small momentum gains during the heat of battle.  We keep a strong bias towards optimism and track progress relentlessly.  When resistance gets crunchy; we’ll make a point to show people how far the effort has come.

Comments (0)
Posted 1 month ago

Strategy 3: Recruit and expand change ownership with "wired" leaders

Here’s our third of five strategies for accelerating change efforts.  Next week, we will publish the final two strategies scoured from fifteen years of Fast Cycle Time implementations.  See previous posts for the model’s introduction and strategy 1-2.

Creating overwhelming momentum for change depends more on leadership experience and capabilities than raw numbers or balanced representation from every stakeholder . We look for leaders who meet four criteria.

First, we want those who are acknowledged “players” in the organization.  Players are those, regardless of title or position, who naturally are called upon for critical deliberations.  These people are organization weathervanes that others monitor to test the political winds of change.  They share a history of getting things done in tough situations.  Normally, they possess a strong dose of formal power and at least twice that in street credibility and savvy.   

Next we look for people who bring wide and trusting personal relationship networks with them. Personal trust is crucial in the initial phases as there is no hard evidence yet on which to base the change effort’s success.  People in personal networks have often worked together before and can be productive immediately.  Large constituencies spread the change virus faster. 

Third, we seek leaders with a deft sense of politics.  All change is political.  This is most apparent just before we reach critical mass when the old way puts up its last fight.  People with good political sense know how to recruit executives to defend the new approach when conflict flares.  Offensively, these folks know how to seize the moment when a strong push can leap frog the change ahead several steps at once. 

Last, we cherish humble yet socially outgoing leaders for there are never enough of them.  These people have the temperament and social skills that enables them to go anywhere at any time and be greeted warmly.  They drain emotion from conflict so that the underlying issues can be addressed.  Most importantly, they are breathtaking in their ability to transform what starts as a change effort into a deeply felt cause that others readily champion.

In today’s world, wired also means finding leaders skilled and nuanced in the latest communication tools.  Using instant messaging, Twitter or other social networking tools, we’ve seen the best leaders establish a persistent presence for the change effort that accelerates momentum to critical mass.

Comments (0)
Posted 1 month ago

Strategy 2: Limit scope, start many fires and always offer an actionable next step

Here’s our second of five strategies for accelerating change efforts.  Over the next week, we will publish all 5 strategies scoured from fifteen years of Fast Cycle Time implementations.  See previous posts for the model’s introduction and strategy 1.

Limited scope shortens the distance to critical mass and reduces distractions.  That’s how firefighters work.  They don’t try to save buildings.  Firefighters destroy them to save people and keep fire from spreading.   For a homeowner with a small kitchen blaze, seeing firefighters axe holes in the roof and walls seems extreme but saving a wall is a distraction when you’re driving for a critical mass of suppression force.

To get to critical mass faster, we use a network approach rather than starting with a central nucleus of advocates and expanding outward across successive orbits of new participants. We build the first network nodes based on where we can get early support and resources.  We’ll by-pass heavy resistance (we can always come back) and look for where the grass is already green to establish a new foothold.  As Herb Shepard, the most insightful change strategist I ever met once said, never walk up hill if you can avoid it. 

Each node starts with a clear local objective, resources including local leadership, and links to other nodes.  We stress using common communication tools and work processes across all nodes to facilitate linking.  Nodes defer linking to others until they’ve created value worth sharing.  Once a node sets roots, we push to establish the next.  We’re told by node leaders that we tend to move just before they’re completely comfortable, but acknowledge it’s the right choice for scaling quickly. 

Growing new nodes happens quickly when we 1) speak the local language, 2) bring what locals consider immediate gifts; and, 3) offer actionable steps they can take immediately.  Gifts are resources, tools or decisions, that delight, liberate and serve local needs.  For example, pre-defined templates that walk people through how to prioritize change targets or design a new work process are universally well received. 

Actionable next steps are critical to shorten mobilization time.  People can burn far too much time deciding what to do first.  Besides, it’s much safer to keep talking than get one’s hands dirty by starting to change something.  We scale the first action steps to local conditions but then push hard to launch an initial task or small experiment.

A limited change scope helps us stack resourcing for success.  The Powell Doctrine of military strategy argues for clear objectives combined with overwhelming force.  Change on the cheap is a low percentage play.  We avoid being suckered into Mission Impossible scenarios that begin with “let’s just get started and adjust as we go.” 

We see this constantly in product development.  Engineers start projects without marketing involvement because they’re are unavailable.  Although well intentioned, once marketing joins, the product definition gets re-written which effectively re-sets the program.  Just as gas engines operate better with backpressure in the exhaust pipe, we find that resisting launching until critical resources are available creates positive pressure in the organization.  It forces executives to re-think current resource allocation priorities and ultimately frees up talent earlier.  This leads us to our third strategy.

Filed under  //  fast cycle time   Herb Shepard   managing change   viral networks  
Comments (0)
Posted 1 month ago

Strategy 1: Bring the Future Forward to Mobilize Faster

Managing change is an established leadership expectation.  What is less discussed is how to make change faster?  Over the next week, we will publish 5 strategies that we’ve scoured from fifteen years of Fast Cycle Time implementations to help make the shift to faster innovation occur faster.  Today we cover Strategy 1:  Mobilizing People Faster by Bringing the Future Forward.

If one cigarette killed people, no one would smoke.  Our animalistic heritage serves us well against immediate threats but when there’s a large time gap between actions and consequences, people aren’t motivated to change.  By bringing distant consequences forward, we can get people to embrace the need for change sooner than they normally would.  Bringing the future closer also reveals opportunities that inform defining the developing a change strategy. Here’s how it works in practice.

In our product development work, we’ll chart a current trend such as schedule slips three to five years into the future.  Next, we’ll make the financial consequences explicit by calculating the aggregate revenue and profit dollars lost due to slips across all projects.  This captures attention but what really gets people talking is when we link the evidence to individual and group concerns. 

This requires personalizing our analysis based on which change constituency we’re trying to reach.  With technical people, we’ll show that if R&D spending and headcount is kept constant as a percentage of revenue; the number of similar projects they can launch in the future will likely decrease since each project will consume more person months.  We can also show that average revenue requirement for each project has to grow significantly to compensate for undertaking fewer projects.  This strikes home since technologists love to work on new stuff.  We then add analysis that shows how the current resource bottlenecks that many believe cause today’s slips only worsens as project schedules expand. 

The key to this approach is that it uses reasonably hard evidence as we adjust the storyline for different audiences.  Sometimes we’ll show the how slips shrink the annual bonus pool, other times we’ll show how longer schedules reduce opportunities for introducing new technology.  As much as possible, we apply conservative assumptions to data. 

Once they’re engaged, we ask them to co-create a change narrative that bridges today to a new future.  The narrative sketches the problem definition, the change objectives and how they’ll get there.  Leaders jump start this by sharing their personal vision for the change effort but then we ask them to give it to others to modify and shape.  We want leaders to play a stronger role in defining the scope of what’s in play and what’s not, since setting this boundary is tough for groups.  Once set, we want leaders to devote their energy to increasing others’ ownership of the effort.  Ownership will accelerate the effort faster than followership, particularly when the road tips uphill.

We jump-start the narrative co-creation process by asking people to write a one paragraph cover story for Fortune and assume it’s published three years from todayThe story retrospectively describes the change journey and what made it successful.   We suggest they include the three signature actions leaders took that accelerated the change.  This often reveals what each sees as the critical challenges and opportunities for rapidly reaching critical mass.

Comments (0)
Posted 1 month ago

The Frontier of Change: Strategies to Acclerate Change

Managing change is an established leadership expectation.  What is less discussed is how to make change faster?  Over the next week, we will publish 5 strategies that we’ve scoured from fifteen years of Fast Cycle Time implementations to help make the shift to faster innovation occur faster.  We’ll begin with the concept of Critical Mass Acceleration.

The Frontier of Change:  Accelerating Faster to Critical Mass

Every day, the headlines are filled with leaders whose promises of change fail to meet expectations.  According to John Kotter, Professor at the Harvard Business School, the main reason many businesses stumble with their change initiatives is that they fail to establish a sufficient sense of urgency.  As average CEO tenure drops from 40 to 30 months, accelerating change is increasingly critical.  Just ask former General Motors CEO Fritz Henderson.  He was let go by then GM Chairman Ed Whitacre just months after his predecessor was fired.  Whitacre declared “While momentum has been building over the last several months…we now need to accelerate our progress”.  

I wrote Fast Cycle Time (Free Press, 1992) to help companies like GM accelerate their product development.  Since then, every work proposal we submit evokes the same response, “We love the Fast Cycle Time model for speeding up product development but why can’t we implement it faster?  You’re the cycle time experts.”  One might call their question a blinding glimpse of the obvious so we took their advice and used Fast Cycle Time principles to help them get fast faster.  This article captures what we’ve learned.

Reducing Time to Critical Mass

Fast Cycle Time taught us that compressing schedules without changing processes, tools and behaviors only makes the same errors faster, reduces quality and in the case of change, adds the risk of a rejection reaction.  As we studied our fastest implementations, a common pattern emerged.  The fastest implementations were quickest to critical mass.  Critical mass occurs when the people and systems operating in the new way achieve unstoppable momentum.  In the best cases, this occurs near or just before the midway point of implementation.  This is also the point at which we can safely accelerate the elimination of the old way.  Actively purging the old approach accelerates the final stages of change because it removes confusion as well as choice between the old and new.  This is especially helpful to support groups that serve multiple masters.

Change programs have three overlapping phases.  The first builds the case for change and mobilizes the effort.  The second is all about implementation and escalates until the old and new are battling toe-to-toe for survival.  This is where we push hard for critical mass.  The last phase accelerates change and solidifies the new by actively wiping out the old approach.

The fast path to critical mass uses overlapping phases.  Phases also overlap based on when people first encounter the change.  Later arrivals are mobilizing when early adopters start implementing. 

We use several tactics to shorten the time to critical mass.  We avoid pilot efforts because they guarantee at least two cycles to reach critical mass.  We pay attention to insuring staffing on new projects is complete at the start.  We recruit change leadership with a strong bias towards people with broader experience because they’re better at handling concurrent implementation issues, multiple stakeholders’ needs and conflict.  We push senior management engagement earlier, consistently and more deeply than they normally expect.  We want to force their issues to the surface earlier to convert them into implementation drivers instead of obstacles.  And we forego one-way education during mobilization and rely on more hands-on involvement. 

As we combed through our successes, five strategies repeated themselves.  It’s not surprising that three of the five focus on the first trimester of the change as this parallels our Fast Cycle Time experience.  Invariably, development projects start too slowly, take too long to build momentum and staff the necessary expertise.  As you’ll see, we’re not advocating setting an earlier and more precise “change” specification.  Rather than resolve uncertainties too early, fast teams build a deep, shared understanding of critical choices and potential issues from the start.

Comments (0)
Posted 1 month ago

Speed Limits: Why Open Source Software Trumps Open Source Hardware

 

If open source collaboration is so powerful, why are virtually all the success stories in software rather than hardware?  To be sure, there are open source hardware projects but you have to look to find them.  What can we learn from this difference?

First, open source software benefits from a common task language.  Every open source project picks a programming language and everyone follows it.  In a hardware project, each discipline has options and approaches within options abound. 

Lesson one:  When everyone speaks the same task language, less time is wasted searching for common understanding or fixing translation mis-matches

Second, the programming language is complete and sufficient regardless of native tongue.  At most, a programmer has to learn 50-100 English words however the use context is familiar.  Hardware disciplines each have their own terms and syntax but they are not separated from their mother tongue.

Lesson two:  Creating an international language provides a strong surrogate that homogenizes cultural differences.

Third, support tools are also open and becoming increasingly standard.  Programmers are used to using online source code repositories to store code.  Project management tools such as Boot Camp provide coordination support.  Hardware projects have similar phases and generic tasks such as concept development, design, fabrication and test but the variance between them and support tools is much higher.

Lesson three:  Process standards and fewer of them drive product development speed

Fourth, there are no major materials differences.   Code is virtual and essential the same character when compared to hardware’s metal, plastic, wiring, chips, etc.

Lesson four:  Minimal materials variation increases development speed

Fifth, software interfaces are easy to standardized (APIs) and change compared to hardware which has to join metal to plastic to circuit boards or what have you.

Lesson five:  Standard interfaces reduce interface problems which are easy to create and tough to find. 

Sixth, software transport, integration and test initiation happen at the speed of light and can occur anywhere whereas hardware requires the assembly and testing of an integrated prototype.

Lesson six:  The virtual world is far faster and flexible than the real world

Let’s extract from these differences principles that apply to all product development:

1.       Don’t underestimate the importance of creating a common task and process language in your projects.

2.       Difference adds creativity but also has friction losses –test the contribution of adding diversity and difference before allowing it in. 

3.       Stay “soft” using simple drawings, mockups, simulations,  etc. as long as possible

4.       Focus on critical interface specifications and project management early in the effort

5.       Keep like activities, and critical interface partners, as close together physically as possible

6.       Stick with simple and common project management/test tools as much as possible

Filed under  //  common language   fast cycle time   hardware   open source   project management   software  
Comments (0)
Posted 1 month ago