Because of Hewlett-Packard’s recent announcement suggesting that they will abandon the PC business, I think you might enjoy reading this piece I wrote – 12 years ago, in 1999 – about the impending demise of the PC business as a high-growth market.

 

The era of the Personal Computer is over.

Not because PCs are about to disappear, but because PC software and hardware will not define the direction of high-growth technology markets in the 21st century.

For those who remember the 1970s and 1980s, the arrival of PCs in 1979-1981 pushed aside the Minicomputer as the defining force for high-growth markets from then on.  The minicomputer market did not disappear.  It simply became a stable, 15%-per-year growth industry.  As a result, the most creative programmers, engineers and business school graduates started going into PC-related businesses.

What has pushed aside the PC?  The answer is the World Wide Web – sometimes known as the Internet.  But this is a flawed answer if you conceive of the Web as something accessed through a PC.

There are two reasons PCs are already obsolete as Web-access devices.

One reason is that only half of U.S. homes have a PC.  And the people who do have home PCs are not satisfied with the type of service they receive or the kind of interaction they must do to successfully access and navigate the Web.

Windows unreliability: Microsoft’s flagship operating system has extremely wide acceptance, but everyone expects to have to re-boot their system at least once per day if they are using Windows on their PCs. [ref: Walter Mossberg, Wall Street Journal, 1999]

Complexity of Windows and Macintosh OS: A general-purpose operating system, such as Windows or MacOS, is designed to allow the computer user to run any application program on the computer. This general-purpose design requires the OS to be complex, have many settings and controls, and the allow for recovery from a wide variety of errors that may occur both in the applications programs and in the OS itself. The average person does not need or want this generality.

An OS is inherently unstable: In the academic halls of Computer Science, I used to joke that Operating Systems “consist of those functions that we don’t understand well enough to commit to hardware.” In other words, we may need to change the functions and interfaces as we learn more about the application software environments, the file and database systems, the communications channels, and so on. If we really understood the requirements well, we would have put the programs in a ROM, rather than loading them at “boot” time.

The second reason is that miniaturization of electronics – and the continued increase in compute power per chip – have enabled portable, personal devices, such as the cellular telephone and the personal digital assistant typified by the 3Com Palm III and successor devices.

Both of these devices have wide acceptance among people who are not regular PC users.  Why?  Because they do one thing well (telephone), or do a small number of things well (Palm III). The computer industry calls these devices dedicated application computers.  The software is loaded in once and runs many, many times without being modified.  The person using them does not see a desktop and “launch” an application program.  A single button causes a function to work.  And it works well.

You didn’t know your cell phone was a computer? But it is! And so is your thermostat, your pool control, your home security system, your automobile engine carburetor controller, and so on.

Who are the people who will use the Web but not PCs?  Here are a few clues:

• They watch movies at home and in theaters.

• They talk on the telephone.

• They buy things in stores, and also from catalogs.

• They buy music recordings and listen to them at home, in their cars and while walking or running.

• They read magazines and newspapers and watch broadcast television.

• They participate in community activities, attend meetings, go to schools and churches, and raise children.

• They are interested in who their neighbors are and what stores are in their neighborhoods.

• The do not program their VCRs.

In other words, they are people like you and me, living their lives in North America at the beginning of the 21st century.

draft 11/29/99                        John V. Levy, Ph.D                             Copyright (c) 1999

415 663-1818                     john@johnlevyconsulting.com                      https://johnlevyconsulting.com

I spent many years managing engineering projects.  It was satisfying work, because the people doing it are very dedicated, they have a culture of finding the best solution, and they get satisfaction from seeing their creations go into the world and be useful (and profitable).

When I began to consult for managers who were counting on IT to provide functions and capabilities to enhance the business, I was shocked to find that IT was regarded as an alien land (full of technologists who speak a different language), and as an untrustworthy department (because of many late or failed projects).

I began to visualize development of IT-based capabilities as being a water pipe, with a Niagara Falls of effort on the input side (IT doing development), and just a trickle of useful results coming out on the business side.  So I set out to discover what was blocking the pipe – or diverting the flow to somewhere else.

While consulting for an insurance company client, found some answers.  Here are some ways the flow of IT is diverted or blocked, and some ways of correcting them:

1. Emergencies pre-empt everything.  The same people are responsible for creating new capabilities and for dealing with crises.  So whenever there is a crisis, all work on the new capabilities stops.

Key projects must have committed resources.  While it’s good to make IT developers responsible for problems in their programs, it is crazy to pull the best people off of all projects to address urgent problems.  Instead, there should be a stable of top trouble-shooters available on short notice.  These people should not be committed to development projects.

2. The project is delivered, but it’s the wrong thing.  When Business and IT don’t speak the same language and don’t plan strategy together, projects can be chartered and completed without knowing what is actually needed for the business.  The result is often a functioning program that doesn’t do what the business needs.

Business and IT must collaborate in strategy and planning.  While they are planning, it helps to have someone who speaks both languages present.  Business and IT also benefit from learning about the other side’s interests and measures of success.

3. Both IT and Operations collude to treat IT development as if it were the same as call-center operations, for example.  But software development is Engineering, not Operations.  So the best software designers leave the organization, and IT projects are implemented by second-tier people who are neither as efficient or as capable as the top-level people.

Software engineering should be recognized as professional work needing the best people you can hire.  Then the physical and management environment needs to be maintained for this professional work.  If you can’t provide such an environment in IT, then the work should be outsourced.  It’s better, however, to have it close to the home office.

With the rapid evolution of IT, it’s easy to get caught up in the rush of new technologies and not pay attention to the core management issues that are wasting a lot of IT effort.  But by correctly managing IT projects and the business-IT interface, you can have more resources available to pursue the latest needs.

 

If you find these ideas useful, you may be interested to read an article I’ve written, titled, Nine Mistakes That Get in the Way of IT-based Business Excellence.  To receive a complimentary copy and to sign up for a twice-monthly e-zine on this topic, please go to http://www.johnlevyconsulting.com/signup.php

 

 

 

I’ve spent many years managing development projects in high-tech industries. My experience teaches me that people doing development are extremely aware that their time and effort is frequently wasted, for a lot of different reasons. The key point for you as a business leader is that wasted effort is the same as wasted dollars.

It’s actually worse than that. Because you depend on deploying new systems, software or business processes on schedule, any delay – or a complete failure to deliver the result – costs you further in savings you expected to have after the system, the product or the service begins. And if it’s a product from your company, you also lose market share to competitors and therefore never realize the life-of-product revenue you were expecting.

One of the key indicators of waste is finding that your managers decide to kill projects because they are not progressing fast enough, or because they are not meeting functional or performance targets. Or they are choosing to live with deficient systems or products because there are not alternatives.

Here are a couple of causes of slow or deficient development projects:

1. Inadequate definition (“requirements”) of the project or product.
2. Reliance on a big up-front “requirements” process resulting in a document that is not revised and adapted regularly as the development progresses.

The first cause may happen due to insufficient information being available to your business managers, so they can’t make informed decisions about either the requirements or the development process itself. The second cause is very common in large organizations or large projects, because they are modeled on construction projects, which are very different from IT or product development in high-tech fields.

To counteract these causes, you may have to change the culture of project definition in your organization. Your business managers need to commit to involvement in the development process. And your project managers need to investigate modern methods of doing development, particularly the “agile” or iterative development methodologies. The main point is to define incremental development milestones that can be visibly demonstrated on a time scale that is short (less than a month, typically), and coupled with immediate feedback and counsel from business managers who are responsible for delivering results.

If you don’t have such processes working in your organization now, it’s time to get going on them. Before you see another big project cancelled for lack of progress.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

John Levy helps executives get business value from every dollar they spend on development. He specializes in rapidly getting development teams in IT and Engineering to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years.   John’s book on management for technology executives, Get Out of the Way , was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com

When you’re responsible for a project, one of the first things you’re supposed to do is determine the requirements for the project. In other words, what exactly do the people who asked for it want? This is much more complicated than it sounds, and much has been written about eliciting requirements and getting them written down in a coherent manner.

In many years of managing projects and teams of developers, I have learned to ask some questions that you might not think of while you’re gathering requirements. You may consider these questions as “tricks of the trade” that could help you keep out of trouble.

Here are the questions:

1. Who has veto power over this project?

One of the most startling outcomes for a young project manager is to have the project cancelled abruptly after pouring a lot of energy into directing and supporting the project and the team performing on it. To head off such an outcome, you should ask this question early in the project definition phase. The answer, which could include the CEO, the Chairman of the Board, or one of the Founders, gives you an idea of who should be included in your regular status updates.

You also can discreetly inquire as to whether those people with veto power have any feedback for you and for the project team, even if they don’t show up on your organization chart (at least not anywhere near your project team). This is the art of politics, and you may as well get good at it.

2. How many of the project team have in the past been interrupted with high priority, preemptive requests from outside their project?

No matter how carefully you estimate manpower and workload, your estimates will be way off the mark if people outside your project can and do take away your team members’ time with non-project work. It is best for you to gauge this “distraction level” as a percentage of the team’s effort, so ask this question early in your project estimation phase.

There are two aspects of this kind of distraction. One is pure non-project work requests that take away team time when they do things like fix a problem with the CEO’s PowerPoint slides, or respond to a key customer’s emergency. The other is when project team members are assigned to more than one project, so that they are switching between the project you manage and a project (or two or three) that are managed by someone else.

When this is the case, you must not only divide the projected available team time by the number of concurrent projects, but also further degrade the time by the “context-switch” factor, which I estimate at 10% per context-switch. In other words, if a team member is working on two projects at once, each project may get 45% of a full-time member at best. For three projects, it’s .8/3 or 27% of full time. Of course, if the context switch happens during a single day, the percentage loss is much worse than 10%. You should make your estimates accordingly.

3. What is the available budget for tools and other capital equipment? Whose approval is needed to actually spend this money?

You want to know how much you can spend on tools before you start, because having the right tools is often crucial to making a team productive. If the development work is in software, this is particularly crucial to your planning – having the wrong tools can not only make productivity low, it can get in the way of your ability to hire the best people for the team.

Having determined how much money is “available,” you also need to find out what it takes to spend the money. Often, in larger organizations, the path to making capital outlays is long and arduous. If it only takes a written justification from you and approval from your immediate boss, then you’re in a relatively normal situation. If a committee has to meet in order to approve your purchase, then you had better find out who is on the committee, how often they meet, and what kinds of purchases they have approved (and disapproved) in the past.

These three questions may all be part of politics. But then knowing what it will take to succeed may influence which project management jobs you take on. Be forewarned and proceed with your eyes open and questions ready.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way , was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.

Architecture of computer-based systems is about design at the top level, including interfaces and protocols. Architecture of complex systems requires knowledge of the technology in all of the components. In software, there are few constraints on how the components are put together, so it requires discipline to keep things simple and consistent. Bring in an architect when you are trying to integrate many existing subsystems.

Architecture is the high-level design of functional components of a complex system. A functional component can be anything from an arithmetic unit in a computer processor to a database system in a software environment. What an architect does is to define the functioning of the unit (without specifying exactly how the function is to be implemented) and the protocol for interfacing to the unit – that is, how to invoke the function and how to transfer data to and from the unit.

Interface and protocols are the stuff an architect works with. Whether the interface is a bus or an object instantiation in an object-oriented software system, the key objective of the architect is to make the system as simple and as consistent as possible, viewed from the functional block level. Why? Because simple, consistent interfaces and protocols are more robust, are easier to understand and are easier to modify when needed. In other words, more agile.

I worked for a number of years at Quantum, a maker of hard disk drives. Quantum developed their own ASICs (application-specific integrated circuits) for inclusion in their hard disk drives. They also wrote firmware (embedded software) that controlled the whole disk drive, from servo (motion control on the read/write head assembly) to buffering (managing the flow of data into and out of the disk drive). As time went on, the complexity of the firmware and the ASICs went up by orders of magnitude, allowing nearly all of the functions of the disk to be managed by a single chip containing a microprocessor, RAM memory and the ASIC logic.

My dream was one day to have designers of the ASIC logic and the firmware logic use a single integrated tool that would allow the design to be completed before a commitment was made for partitioning the functions between hardware and software. Even though firmware runs for the most part as a sequential process, and ASICs for the most part run as parallel pieces of hardware logic, their functional blocks have a lot in common. Even more important, the definition of an interface between the functional blocks are almost exactly the same for firmware and ASICs.

Hardware and software can frequently be traded off – complex hardware can be simulated by large software programs running on simple hardware, for example. Why not defer the decision as to which parts will be committed to hardware until after all of the design is done? I visualized a designer completing the design of hard disk control logic on an automated design system, then trying out several different variations on partitioning the logic between hardware and software before committing the design to a chip and firmware, each of which would then be automatically generated by the design program.

Alas, the design automation software never converged to a degree that allowed such a tool to be built. ASIC designers still have to ply their trade using design tools that understood logic gates and clocks, sequences of inputs and outputs on signal lines, and parallel processing of signals (and testing for race conditions). Firmware designers, on the other hand, have to write their code as sequences of instructions that execute on a computer processor, access memory, and perform input and output operations using registers (many of them embedded in the accompanying ASIC).

The architect of a disk drive thus must understand both worlds – logic and software – as well as several others, including read/write, servo and mechanical technology. Fortunately, the boundaries between these areas have evolved only slowly. However, in the software arena, boundaries between functional blocks of a system are much more volatile, because there are very low barriers to invention of new ways to interface between blocks or to perform protocols.

Therefore, the software architect’s job is even more critical, because simple and consistent interfaces and protocols will not occur naturally. There are two reasons for this. First, software designers tend to delight in inventing new ways to interface between modules – because they can. And second, legacy systems always demonstrate limitations that must be overcome as systems evolve.

To maintain agility within software designs, an architect must balance the need for evolving functions with the conceptual integrity and simplicity of an initial design. This is why the best architects are constantly struggling to reduce complexity while integrating more and more functions into an evolving system.

If you think that the work of an architect is only needed at the beginning of a project, consider what will happen if you let existing interfaces and protocols persist forever as you integrate diverse systems into a working whole. The battle for robustness and maintainability will not be won by letting every subsystem persist unchanged. Instead, you need a constant reevaluation of all of the interfaces and protocols. When your designers are facing such problems, bring in an architect.

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, was published in May 2010.

For more information, please visit his website.
Email him at: info (at) johnlevyconsulting.com , or call 415 663-1818

Summary
Business managers often find themselves bamboozled by technologists and their managers. After spending a lot of money on IT or Engineering, they still don’t have what they want. Here are nine ways a business manager can ask questions to improve relations with the technologists.

If you’re a business manager, you are dealing with a wide range of people and problems. Some of those people are technologists. And, no doubt, some of the problems you deal with are related to technology.

Let’s acknowledge right away that a key problem with technology is that it keeps changing. For example, just when you thought you had a grasp of what it takes to implement a computer program to support your sales staff using a centralized computer system, the systems moved out onto the desks of each of the sales people. And just when the PC-based systems seemed to be manageable, the sales people started carrying smartphones around in their pockets and asking for their information to be delivered to these devices.

Add to that the shift to “cloud computing” and “virtualization,” and you find yourself running fast just to keep up with the terminology, let alone the management issues involved in successful IT implementation.

However, if you’re an experienced manager, you know that there are certain principles of management that apply no matter what you’re dealing with. After all, people are people; organizations, even technical ones, are made up of people; and you have a strong grasp of how to listen to, influence, and manage people. But somehow, the technologists seem to be getting more difficult to manage.

Here are some principles and ideas you can use to interact more successfully with technologists – and their managers, whether they are in your organization or outside of it.

1. Have confidence that you are capable of understanding what’s happening in technology. While there are shifts going on that are causing a lot of turmoil in the IT and Engineering worlds, none of the underlying technologies are so sophisticated that you can’t grasp their significance. After all, you have dealt with much complexity simply by being a business manager. People are much more complicated than machines.

2. When a technologist or a technical manager communicates with you, it’s OK to insist that things be explained in terms you can understand. If the person explaining things to you refers to acronyms and terminology you haven’t heard before, ask her to explain what they stand for and what they mean. It does not diminish you to admit that you’re not a specialist in the technology area being described. Keep asking questions until you get an explanation that clarifies things to your satisfaction.

3. Ask questions that clarify the significance of the technology. A technology is significant if it (a) displaces some other technology, (b) makes some existing activity or product a lot cheaper, (c) enables information-gathering or analysis that was previously impossible or too expensive, (d) creates a tool that will vastly improve a person’s efficiency at doing something, or (e) creates a material or process that will lead to a wide range of new products or services. The technologist should be able to explain to you which of these is about to happen, and how it could impinge on the business activities that your organization is engaged in.

4. Ask whether there are competing technologies that could displace the described technology or make it irrelevant.

5. If someone is suggesting that you make a large investment in a new technology, ask whether there are lower-cost alternatives that will suffice for an interim period. Evaluate the risk of being left behind relative to your competitors. Also consider whether you may have more options in the future if you wait before committing to this investment.

6. Expect software development to have a highly variable cost or time to complete, because it is hard for technologists to predict what it will take to develop a piece of software. Software development is not yet a stable engineering discipline the way, for example, building construction is. Every major software development project includes a significant amount of experimentation, because there is not a “reference manual” that tells software people how to make each component. In addition, when you put together a bunch of software pieces, it requires a lot of testing to make sure there are no major malfunctions in it. And even with a lot of testing, there are no guarantees, because there are just too many possibilities to test them all.

7. Get in the habit of asking technology managers to commit to showing you a working prototype of anything you’re asking them to build. Particularly with software, it is normal for your idea to evolve after you see a working model. So it’s best to ask to see the working model often, having the implementation done in small stages. If it’s not going the way you want after, say, 8 demonstrations or 6 months, you can call the whole thing off, or start over in a different direction.

8. Don’t ask Engineering or IT to work overtime for extended periods. You wouldn’t do that with Accounting or Legal without expecting a lot more errors to result. The same is true for development work. And the result of development errors can be disastrous when the product or service you’re developing is delivered to external or internal customers.

9. Develop trust between yourself and your IT or Engineering managers by learning about their challenges and opportunities, and by teaching them about yours. The more you can understand each other, the better your cooperation will be. Invite one of their staff people to sit in on your staff meetings or be resident in your area. Send one of your own staff people to become familiar with their activities. The less mystery there is about their decisions, the more trust there will be.

If you’re not getting what you want from IT or Engineering, consider the possibility that at least half of the problem is on your side. You can take action to develop a good working relationship with the technologists. And while you’re at it, you’ll probably find that they actually want to understand what you’re dealing with as well.

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, was published in May 2010.

For more information, please visit his website – johnlevyconsulting.com
Email him at: info@johnlevyconsulting.com , or call 415 663-1818