Why do these projects fail to complete? Here are three major causes of IT project failure.

1. They’re not defined well

If the sponsors don’t define the project well, the people implementing it will apply their own ideas to define the outcomes.  This usually leads the project astray, because no matter how technically competent the implementers are, they are not mind-readers and they rarely have a clear idea of the business purpose of the project.

The best way to define an IT project is to start with the end – defining the measurable impact on business parameters that the project is intended to have.  From these, derive criteria for completion including demonstrations of the key capabilities and measurable test results.  If this seems hard to do, then you need to review why the project is being done.

2. The people doing the work are not a team

People implementing the project need to behave as a team.  If they don’t, the project is likely to fail.

You need good teamwork to get a project done.  What’s good teamwork?  It’s good communication with blaming; it’s clear acceptance of accountability for doing what each member said he or she would do;  it’s working cooperatively to solve the inevitable problems that come up.

If your implementation team is split across town or across continents, there needs to be active management of the communications so that the teamwork criteria are met.  Agile development, which relies a lot on self-directed teams, requires outstanding teamwork before any benefit from the Agile principles will pay off.

For example, a client company I worked with had parts of its web implementation team split between two facilities 750 miles apart.  When not enough results were coming through, the manager decided that Agile methods would solve the problem.  But the two parts of the “team” did not trust each other and each blamed the other part for the lack of results.  Only after bringing the top dozen people together in one room for two days per month did they begin to work out their common goals and start to solve the problems.

Leadership is also required in a self-directed team.  Leadership in this context means actively managing the team process and the management.

3. They don’t have enough resources or the right resources

The effort needed to complete an IT project is often underestimated.  A combination of implementer optimism and wishful thinking on the part of the sponsor conspires to make the budget for many projects inadequate.  This causes an unpleasant surprise when the project is nowhere near complete when the budget is spent.

You also need the right resources.  People who have the skill and competence to plan, design, code, test and deploy the program are necessary.  If any part of this sequence is weak, then a lot of time and effort can be lost during the project.

The implementers need the right tools, including software tools and a work environment in which they can use them properly.

Under-estimation of the scope of a project may lead it to grow too big for a single team to accomplish within the time required.  That can lead to further complications, because multiple-team projects require segmentation of the effort into coherent modules, and then the integration of the whole project has to be done by an integration team.  So when you discover the realistic effort needed to accomplish the project, you may also have to rework the whole management structures used to implement it.

If you want to insulate your company from IT project failures, you need to pay attention to project definition, team formation and adequate resources.  Then you have a chance to beat the odds and reap a successful conclusion to your IT project.

Software people are different, so their managers need to be able to deal with the difference.  Effective software managers know what’s critical to a well-functioning software team and those managers get good at providing it, even in the face of obstacles.

Obstacles come from upper management that doesn’t understand how software, and software people, is unique.  As a result, they assume that a manager who has skills in Operations can just as well manage software.

I’ve seen IT shops where the best software people left the company quickly after being treated as if they were call-center operators.  For example, the management assumed that the software people could be located anywhere in the building, that they didn’t need any special whiteboards to keep track of their project information.

Why should you care? After all, can’t you just hire the brains you need for software?  Well, not so fast.  You’re competing with every company in the world for the same kind of brains. Unless you’re in an entrepreneurial, fast growing, innovative company, software people will not prefer working for you over going to work in a more exciting environment.

IT is undergoing rapid change, primarily driven by the availability of cloud services.  But the cloud just moves the data centers to somewhere else. If you look closely at internal IT activities, you will realize that IT is itself a software-intensive activity.

This sounds self-evident, but it’s not a joke.  It’s a reality that many financial and operations executives fail to understand.  Everyone, from the business analysts to the website deployment people are not just software users – they have to understand software principles to do their work.

Business competition will come from new players, and from old players who master software tools and the business possibilities opened up by software.

As software becomes an integral part of business, there is a subtle shift in what management has to do and to know.  You now need staff – or consultants – who are knowledgeable about software and its workings.  And from them you need to learn what software means for the future of your business.

Is there something you’ve learned recently about software?  I welcome your comments.

There’s been a lot written about how IT and business are misaligned.  See for example, Susan Cramm’s excellent book.[1]  But how do they get that way?  One cause is that many IT people don’t understand business.  Another is financial invisibility of IT due to budgeting processes.  But these are not the big killer causes.

I believe there are three major causes:  physical distance, psychological distance, and IT overload.

Physical distance of IT from the business leads to isolation in many ways.  One of my client companies had their IT people in a city 750 miles away from the home office.  Not only did this impose communication barriers, it meant that the IT people were living in a different culture from the home office people – even though both locations are in the United States.  Of course, when you add in the distance to some of the offshore contractors who are handling some IT services, physical distance means even more cultural distance.

Psychological distance can be caused by having objectives that don’t relate to business goals and by being managed in a “silo.”  For example, IT may report in to the CFO, and management metrics may relate only to financial performance.  As long as IT is budgeted as an operational expense, then no amount of encouragement will get IT managers to view what they’re doing as a strategic investment.  This can be aggravated by failing to include IT people in business planning.  Finally, I’ve seen IT organizations where the business tools used by the rest of the business are not in use in IT.

IT management overload is the third major cause of misalignment.  Beyond the usual overload caused by rapidly changing technology and shifting responsibilities (associated with Cloud services, for example), IT management is typically trying to do more with less budget.  As the pressure to perform increases, IT management concentrates on operational measures rather than business metrics.  In addition, technology shifts are raising the cost and complexity of legacy system support.  So IT managers tend to focus on reducing these burdens, rather than looking for new initiatives to support.

Where can we start to correct the lack of alignment between IT and business?  After addressing physical location and reporting structures, the most productive way to get alignment is with common metrics.  Look for business metrics that are relevant to concrete business results and are particularly dependent on IT service delivery.  Then make sure that IT managers understand the business metrics.  Finally, make sure that they buy in to being measured by these metrics.  To do that, of course, it is best to include them in business planning processes – and not just as number-providers.

What are your experiences with IT – Business alignment?  I welcome your comments.

The Cloud

Everyone touts “the Cloud” as the latest thing, yet many aspects of the Cloud have been around for years. If you’re using Salesforce.com, for example, you’ve had software as a service (SaaS) for as long as you’ve been a subscriber. In my office, we use a CRM (customer-relationship manager) service named Highrise by a company called 37Signals. There are many satisfied users of these cloud services, but it’s best if you understand the tradeoffs and pitfalls. Here’s a quick summary:

What’s most unusual about the Cloud? – it accommodates temporary load variations

Using software that’s running “in the Cloud” gives you the capability to radically change your usage of the computers. So if you have a temporary load that is 100 times your average load, you can “provision” a bunch of servers and cover your needs in just a few minutes’ interaction with the cloud service.

What’s the biggest caveat about using the Cloud? – you have to be using standardized services

Cloud service providers can give you what you want in a moment’s notice. But unless you’re using a service that is standard – that is, not much different from everybody’s else’s service – you will not find it economical. So don’t look to cloud services to differentiate you from your competitors, because they are probably using the same or a similar service, too.

What’s the payoff of using the Cloud? – OpEx, not CapEx

You pay only for what you use, and it’s usually a lot less than the cost of provisioning your own data center and buying the software. So using the cloud lets you get IT work done efficiently on operating expenses alone.

What else could be a problem in using the Cloud?

1. Security – don’t plan to put your most confidential data into the cloud. For the data you do put in the cloud, make sure you have adequate backup and restore capability, or suitable data duplication.
2. Availability – be sure to check on service level agreements (SLAs) from your cloud providers. Think about how many minutes of downtime a year you can afford, then compare the offerings.
3. Competitive services – there aren’t many cloud service standards yet, so moving from one cloud provider to another can be a problem.
4. Rogue IT – If you’re managing IT for a large organization, you may discover that department managers are buying their own cloud services. This may be efficient and effective for them, but it could undermine your efforts to get IT to be consistent and effective across the organization. Get out in front of your users’ needs, and offer consulting on cloud services to your departments.

For a longer essay on the ups and downs of cloud services, I recommend you read Robert Keahey’s article titled, “The CFO’s Guide to the Cloud”.

Agile

Agile software development originated with the “Agile Manifesto” in 2001. I like to describe it as a bunch of software developers who got together and said to themselves, “We’ve been so badly managed for so long, surely we can do better ourselves.” So they laid down 4 values and 12 principles for software development. Since then, Agile has proven to be 2 to 3 times more efficient than previous “waterfall” methods for many types of software development. And the Agile principles have begun to be taken into other areas of management. Here are a few key things you should know about Agile:

What’s most unusual about Agile? – progress is more visible

Agile methods work by dividing up a large project into increments that can be done in short intervals. The interval chosen is usually 2 or 3 weeks. At the end of each interval, the project team demonstrates working software. Since you can see the software working sooner and more often, you get more confidence that the claimed progress is real, because you can see it.

What’s the biggest caveat about using Agile? – it requires more involvement by business people.

A development team in an Agile project requires daily access to a business person who is responsible for the results. This guarantees that software developers can talk over what the requirements really mean. It also requires the business person to be on-call every day, as well as present in person at the end-of-iteration reviews every 2 weeks. Don’t expect an Agile team to be effective if you don’t provide for this level of time commitment by one of the business leaders.

What’s the payoff of using Agile? – you can keep up with changes in the market and in your business priorities.

At each interval the priorities are set for what should be done in the next iteration, so you can adapt the project to changing conditions as you go. This helps to keep you from paying for a lot of work on the wrong thing. In fact, this could allow you to kill a project after only 10% of it is done, rather than having to wait until 60% to 80% of it is done to find out it’s the wrong thing.

What are other benefits of using Agile? – Agile could infect your company’s project management system and make everything you do more efficient. At the very least, using Agile for software development in IT will make your business people and your IT people work closer together on major developments. And that couldn’t be bad, right?

I have always felt that engineering is not only an honorable profession, it also leads to a practical lifestyle that values inquiry, problem-solving and efficient solutions to the challenges in life.  So you may not be surprised to learn that I am a fully qualified lifelong nerd.  I love examining things to discover how they work.  And the more complex the mechanisms, the more interesting they are.

This is where it gets to be a problem.  When I invent something new, like a part of a computer, I revel in the complexity of the thing I’m building.  As long as the complexity serves a purpose, such as actually making the thing do what it’s supposed to do, my brain is tweaked in pleasurable ways when I contemplate the complexity.

If you’ve been reading any of the recent pieces about Steve Jobs, you’ll have understood that part of his brilliance was being able to conceive of simple and easy-to-use products that “just work.”  I worked with Steve in the early days of Apple, and I can verify that it was a challenge being an engineer in a place where the visionary boss kept revising the product based on his latest concept of simple.  Yet even engineers have a principle they repeat to each other to counterbalance their tendency towards complexity – the KISS principle: “Keep it simple, stupid”.

A quote attributed to Einstein says “Make it as simple as possible, but no simpler.”  This teaching admonishes us to simplify our theories, but not so far that they no longer apply to the real world.  Jobs’ vision was to make products that contained complex technology but worked well and intuitively for the common person.  And from that basis, he led the creation of products that have changed the way the world works.

So does this mean that I’m giving up on complex ideas and mechanisms?  Not at all.  The mental contortions I need to undertake to understand complicated things still give me pleasure.  And I believe they keep my mind alive in important ways.  The key to living with such an engineering mind is to keep it from running my life.  I still listen to J.S. Bach’s music with satisfaction at the complexity of the counterpoint and harmonies.  But I also meditate on emptiness to keep the logical brain in check.

The next time you hold a complicated piece of consumer electronics in your hand – such as your mobile phone – take a moment to reflect on its complexity and its simplicity.  Encapsulating one of these in the other is an art.  And to accomplish that encapsulation, you need both engineers and artists.  Long may the engineers and artists work together.

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                      http://johnlevyconsulting.com

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

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. http://bit.ly/9pX1wS

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

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. http://bit.ly/9pX1wS

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

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

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, Get Out of the Way, was published in May 2010.

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