Agile programming works for the solo developer

Agile programming, a.k.a., extreme programming (XP), has a lot to offer the lone developer. Learn how agile programming's practices can bring order to solo development efforts.

You may not realize it, but if you’re a software developer who works alone, you may already be using a lot of the concepts behind agile programming, also known as extreme programming, or XP. Of course, certain agile programming practices, such as pair programming, simply don’t apply, but the organic nature of the agile methodology easily lends itself to rapid application development, even for the solo programmer.

I’ll step through the relevant practices of agile programming and how they can facilitate application development in the one-man shop.

Agile programming overview

The agile programming methodology is divided into four activities and deployed with an iterative style. Planning, designing, coding, and testing are all performed in bite-size pieces. These steps are revisited when needed or according to schedule.

When you’re developing alone, it’s easy to just dive in and assume that you’ll be able to handle whatever problems arise. Agile methods can facilitate the process, however, and will actually help you avoid the lag that comes from struggling with a less organized approach.

I’m an independent application developer, as are many in the current economic climate. As of this writing, I’ve got four separate projects. While I can easily manage requirements and progress status for each of these endeavors, I’ve found that the time needed for sourcing, ramp-up, and development is greatly reduced simply by applying a little order to the chaos.

Borrowing relevant agile programming methodologies has worked quite well for these projects. For one thing, agile programming isn’t heavy and doesn’t require an inordinate amount of overhead. Also, every piece of planning is immediately useful, and my clients get a sense of constant contact and the instant gratification of regular updates. The practices defined by agile programming help me put a simple structure behind my work. This lets me focus on getting things done, but it also supplies the environment I need to adapt to and incorporate changes without disrupting progress.

When you’re working alone on a project, planning is easier with the agile methodology than with spiral development or the other methods I’ve worked with. In fact, much of the process comes naturally to the lone-wolf developer. By picking and choosing the pieces that fit, these practices are well suited to working alone.

Agile planning

You may find that you’re already using many of agile programming’s planning practices, although perhaps in a more informal manner. Try tweaking your diligence slightly, and you’ll discover some of agile programming’s tremendous benefits in this area.

User stories

User stories are a way of capturing what I call “the flood.” This is similar to requirements gathering in traditional development methodologies, but it differs in that technical details are omitted and work to be performed is described in plain English, broken out into two- to three-week sections. Each user story is written onto an index card and used to plan releases.

Since one-man projects tend to be small, I generally break the user stories into shorter duration blocks. Of course, this goes against the rules of the “planning game” and ultimately quickens the iterative rhythm; however, the same basic principles apply.

Releases

A release consists of user stories grouped together based on dependencies and business need. Agile programming releases are not partial deployments but rather represent completed, logically grouped portions of functionality. Scope or duration can determine a release, and functionality is chosen by common sense and priority.

As with team projects, keep releases short. Each release comprises several iterations and is largely determined at the beginning of the project. Organize releases by grouping the user story index cards together. This allows you to keep the customer satisfied with frequent deployments, and it helps keep the focus on the big picture.

Just-in-time planning

Once you have an idea of the releases, determine your iteration length. An iteration should be one to three weeks in length, and there should be three or four iterations per release. Even with shortened user stories, I’ve found that sticking to the low end of this guideline works on lone projects, as long as I make sure that all iterations are about the same length. Otherwise, it’s too easy to break away from the agile model.

Define iterations by selecting the most important user stories and breaking them down into programming tasks. Involve your client in deciding what task has the highest priority, and always plan to complete it first.

Iteration planning should be done at the start of that iteration and not before. This may seem somewhat shortsighted, but it keeps you focused. Discrepancies will be resolved in future iterations.

Designing the solution

Designing your solution with the agile methodology is simple. It’s spread out over the course of development, rather than being completed up front.

Class cards

Create index cards representing objects and classes. Use the cards as you would boxes on a diagram to demonstrate the objects’ relationships. Keep it simple, and refine the layout with additional detail when planning an iteration.

Refactoring

As you move through the project, take time to clean up your code and consolidate functionality. This is called refactoring, and it allows the system architecture to develop logically and organically. Every iteration should include time for restructuring; the class cards can show where it may be necessary.

Spike solution

When you encounter a tough problem that lacks an immediately apparent solution, create a spike solution. This is where you try out different approaches in code to make the correct solution more apparent. This happens all the time in independent development, and it may not require the level of formality that agile programming calls for.

Other design principles apply as well, but many are somewhat inherent when the team is a single person. For example, it’s a good idea to name objects and other system elements consistently, but as an individual, you probably don’t need to formally create a metaphor.

Coding guidelines

Much of the coding guidelines for agile programming refer to management of teams, but a few concepts are worth adopting.

Client contact

Frequent contact with the client is crucial for the deferred planning of this methodology. Not only does frequent contact help clarify details and prioritize tasks, but it’s also a great management tool when you work alone. It gives the client confidence in your ability to deliver and keeps the client abreast of your progress.

Testing framework

Create unit tests before writing code. This might seem a little like overkill for small projects, but it actually keeps the scope in focus and limits development to the requirements. Code enhancements and additions must be completed in a separate iteration, facilitating quality assurance.

Even though it’s a good idea to create a testing framework, less formality is required for one-man projects. Since I usually wind up writing code and interfaces, I use preliminary interfaces with debug flags as my test mechanism for back-end functionality. Although this isn’t as stringent or long-lasting as the agile methodology’s preferred practice, I’m comfortable that it meets my needs.

As extreme programming enthusiasts are quick to point out, the process is designed to be modified to fit your needs and changed when it isn’t working.

Test before moving on

Once you’ve completed coding a particular piece of functionality, make sure it works before moving on. This is one of the ideas behind creating unit tests up front. When the relevant code has passed the unit test, it can be integrated. After completing all tasks for a user story, apply functional tests to ensure all requirements are met. When you find serious bugs, modify your testing to check for them after they’ve been fixed.

When you’re working alone, this is pretty much the natural progression of testing code anyway. By creating formal tests before writing code, it’s evident whether a piece of functionality works or not.

Bringing structure to the soloist

These are some of the principles of agile programming that apply to solo development. I picked up these habits on a recent project as an experiment to see if I noticed any improved efficiency. It took about a month to really get into the habit of not solving problems before their time and being diligent about refactoring, but my productivity increased once I got a rhythm going.

I really like the way the client took an active role through continual contact, and forcing myself to create test cases before writing the code facilitated development. If you’re a single developer, agile programming can give structure to your process.

HR Online Recruitment Mashup

Do you recruit using naukri.com or Monster or any online recruiter? Do you want a way to automatically post your jobs internally and externally? We have a very competitive offering that can help you do just that.

This business mashhup combines the implementation of an internal recruitment process with different kinds of job services, which are available in the internet or a company's intranet. These (online) services enable to find, recruit and/or retain potential candidates.

Every organization has continuous or recurring staff requirements. This Mashup can help to optimize and standardize the entire application and recruitment process.

In some cases there is a lack of human resources - not enough/unsuitable job seekers. Hence, it is very promising to integrate different kinds of job service, e.g. sourcing of candidates through Job-Boards or other stored date - into the recruitment process.

This mashup supports the enhancement of the quality of resources recruited and the reduce the time it takes for the whole application and recruitment process.

For details and further discussion contact businessmashupsllc[at]gmail.com

Mashups: The next major new software development model?

Even a cursory examination of what people are doing every day on the Web right now tells us that mashups — also known as ad hoc Web sites created on the fly out of other Web sites — are indeed happening in a large way, albeit in simple forms, by the tens of thousands online every day.

But inside our organizations, both in the IT department and in business units, mashups are a much rarer phenomenon. And in fact, this is one of the classic hallmarks of the Web 2.0 era; the much larger community of the Web as a major source of innovation and leading edge behavior that subsequently moves across the firewall and into our workplaces.

However, the topic of this blog is aimed at the application of Web 2.0 to the enterprise and so whether mashups will be a significant new model for application development inside our businesses anytime soon is still somewhat of an open question.

Since the mashup story is primarily being driven by spontaneous activity at the edge of the Internet, an accurate and updated picture of what's actually happening with them is harder to make out than if it was being driven by a centralized industry effort. And as it turns out, this makes what's happening richer and more exciting than it would be otherwise while at the same providing significant challenges for those that want to take these compelling ideas and apply them deliberately to solve business problems.

To bring folks that are just joining the mashup conversation up to speed on why mashups are so exciting, I'll start with my take on the key aspects of mashups from a value proposition perspective.

Key Aspects and Benefits of the Mashup Approach

• Effective leverage of Web parts and the Global SOA. Mashups are generally built out of the bits, pieces, and services of other Web applications that already exist, adding code only when it can't be sourced from internal or external suppliers or to provide integration "glue" between the parts. This reuse can quickly and easily leverage millions of dollars in previous investment and results in a "building on the shoulder's of giants" effect. Like the visual component marketplace successfully built around ActiveX in the late 90's, mashups are a form of reuse that actually works but on a much larger scale than ever before. See ProgrammableWeb's open API cloud and WidgetBox for a good example of the vast array Web parts that are now widely available.
  

• Simple, lightweight software models and services. By focusing on the simplest possible techniques and formats, Web mashups appear to be successful and widespread primarily because just about anyone can and are creating them. Mashups are typically built using techniques like cutting and pasting snippets of Javascript, using feeds and XML to connect the various parts together, and even one-line Javascript inclusions that can pull in and integrate an powerful external component, such as Google Maps or a YouTube video player, that originally required a massive investment from its creator. There sometimes seems to be no limit to the effort to lower the barrier to consumption of these Web parts. Both Google and YouTube are poster children for easy Web part consumption and have reaped corresponding rewards. Google makes its AdWords and Maps widgets incredibly easy to install and deploy while YouTube even puts the hosting code next to each and every video on its site. Finally, mashups are 100% pure Software as a Service (SaaS) and require no installation, updates, plug-ins, admin rights, or anything but a garden variety Web browser and the mashup's URL to run.
  

• A focus on self-service and DIY. As I alluded to above, mashup development can be just as much for everyday Web users as it is for professional software developers. Like so many things on the Web that put the power of publishing and participation into everyone's hands, mashups have the potential to give all of us the ability to create real, useful software. And while end-user mashups will remain in the bottom half or one quarter of the software complexity spectrum, it means that applications that could never have been justified on a build-vs.-buy perspective (and took too long to acquire to help) are now possible These apps can now just be created by users — and groups of collaborating users — on the fly as they need them. This has the potential to further enable the productivity of knowledge workers as well as release The Long Tail of IT demand. It could also reduce the application backlogs that continue to bedevil IT departments and their customers everywhere. And to re-emphasize, it's because mashups use such simple techniques that jsut about anyone can now create the views, dashboards, and even real software apps that let them get their work done better and faster without unnecessary bureaucracy (some bureaucracy is required as I indicate below). I've been collecting real-world examples of this in the workplace and will share them in an upcoming post.

There are numerous smaller, ancillary benefits of mashups including the fact they are Web-oriented and 1) can leverage link structure, 2) tend to be more open and visible which results in more transparency and information sharing, and 3) their content can even be discoverable by search if some care is taken. In this way, they become part of the Enterprise 2.0 story as well, particularly if they are socially enabled. Fortunately, a good number of widgets, such as those from txtDrop and MyBlogLog, make it easy to add simple social aspects to mashups to enable their full power.

This, however, doesn't mean there aren't challenges and a few drawbacks to mashups which I'll highlight below. For now, it's enough to keep in mind that the three major benefits including high-levels of reuse and leverage, models that support rapid, easy development and integration, and a focus on DIY by anyone from expert developers to newbie Web users.

The Challenges and Opportunities of Mashups

Mashup Challenges

• Deconflicting the two major mashup models. Right now mashups are happening mostly "in the wild" with users taking their blogs, wiki pages, FaceBook profiles, and even ordinary Web pages and covering them with badges, widgets, and gadgets from elsewhere on the Web. On the high end of the complexity spectrum, there are over 2,000 developer created mashups presently available. There is also now a growing body of tools from commercial software vendors that also try to bring the apparent advantages of mashups to the business world, both on the Web and in our intranets. In general, these two mashup models are quite different from each other. On the consumer Web we have the natural, emergent mashup phenomenon as numerous Web parts suppliers and their consumers try different strategies out and sometimes hit upon the models that work best (which appears to be things like one-line includes, cut-and-paste, and smart widgets that make integration easy, with Google Maps being another great example.) On the vendor side, enterprise mashup tools try to add missing enterprise context like security, support for local SOAs, and so on, as well as a mashup development model, usually by choosing a particular Web component standard and providing a visual IDE that makes it easier for the non-HTML savvy to create mashups. These commercial mashup application models try to a priori figure out what will work best and in this they may be making the mistake of ignoring the vast laboratory of the Web that is already proving out highly effective models for mashup parts and integration strategies on a large scale. There is also a skill and open/closed barrier between these two approaches that tends to prevent the movement or migration from model to the other. My best guess is that the commercial mashup tools that will succeed the best will eliminate this barrier or at least greatly reduce it.
  

• Too many widget formats. Both Microsoft and Google have their own gadget models, NetVibes has the compelling Universal Widget Architecture (UWA), and OpenAjax has no component model per se but vital strategies for making Web parts work together in the same mashup. Even the venerable and respected W3C has gotten in the act with a first draft of the Widgets 1.0 specification. Visual tool support is important to fully enable mashup development and realize the productivity potential and this support requires a consistent widget format. But the proliferation of widget models (both ad hoc and formal specs) makes visual tooling expensive and time-consuming to implement. And though the greater Web has been relatively successful so far without them, enterprises are not yet anxious to start figuring out which widget models are the most important. Unfortunately, no obvious solution is on the horizon though some early techniques have formed including wrapping the different component models into a standard widget wrapper.

• Not enough Web services exist in our enterprises or on the Web. While the number of open APIs on the Internet continues to grow quickly, there just aren't enough Web services available to supply the data and back-end functionality to mashups. Most data on the Internet and our intranets are still in static Web pages in the form of HTML. While the growing adoption of XHTML helps a little, the greater service-enablement of the Web will take years and years. In the meantime we need to quickly service-enable our silos of Web-based information if we are to fully exploit it. Fortunately, this challenge can now be partially mitigated with companies like Kapow and Yahoo with Pipes, which are providing just such tools to make this possible. Also note that this challenge is one reason why widgets have grown so popular, since they offer both a data connection back to the server they came from as well as a visual aspect that allows the information to be seen and integrate with. Thus widgets are ideal for consumption by providing a sort of easy-to-use "visual SOA."
  

• Security and identity need to be sorted out. The most useful mashups will involve Web-based creations that are powered with our personal and business information. For now, most mashups don't require (or support) logins that allow it to collect information from your private repositories of information. While initiatives like OpenID have the potential to resolve some of these issues, there is a lot of work to be done before the average user will trust a mashup with access to their private information. This shortcoming fundamentally limits the real value that mashups have the potential to provide.

• No common creation metaphor. Other major Web 2.0 platforms such as blog and wikis have very simple, well-known usage models. There is a save button, an edit button, and either a reverse chronology of posts (blogs) or a series of page revisions (wikis). However, other than the aforementioned simple cut-and-paste model, nothing has really emerged in a similar vein for the creation of mashups. This will resolve itself slowly as some widgets now have configuration popups or easy code generators to get what you need done without needing to be a Javascript expert. However this is a far cry from having a development model that is generally well understood by most people and well documented. I often say that spreadsheets and Microsoft Access are the end-user development tools most of us have today and they offer some insight, as well as blogs and wikis, into what a workable model might look like. Offering some hope, mashup vendors are exploiting the near ubiquity of the blog and wiki model and IBM has merged mashup development with wikis with QEDWiki and Dan Bricklin has done something similar with wikis and spreadsheets with WikiCalc.

Mashup Opportunities

• Defining the essential ingredients of a successful mashup ecosystem. This is about conveying a clear conception to the marketplace that we really are moving more from green field development to a world where we assemble our software out of the rich content and functionality we now have ready access to on the Web and our SOAs. Other ecosystem questions: What kind of Web services do you need? How about adapters to legacy systems and content? Should you encourage mashups to be the foundation for other mashups? How do we guarantee compatibility and interoperability? These and a lot more issues about how to create a successful mashup ecosystem need to be better articulated than they have been to date.

• Addressing the tension between the two major styles of integration. Most integration today is done up front with lots of testing and configuration control and baselined code from your external suppliers. On the other hand, mashups rely on live pulls of code from your supplier and are a much more extreme form of combining our systems together. The very word "mashup" conveys how ad hoc this really is. This new live model of integration has security, testing, and version control issues written all over it. Google and some of the larger suppliers are getting a handle on some of these but market leadership on this could go a long way.

• Providing effective "enterprise context." Mashups are a creation of the consumer Web and are not always ready to "play" in the enterprise space. To even get a foot in the door, enterprise mashup tools need to have solid stories around single sign-on (SSO), LDAP, JSR168 (portals/portlets), legacy integration, management, monitoring, RSS strategy, etc. Most enterprise tools are still falling short in these categories and will likely not get broad adoption until they address them.

• Distribution and consumption. Many of the ideas that the consumer Web has come up with for Web parts to be highly viral, easily distributable, and eminently consumable are also important strategies that we must think seriously about moving into our SOA initiatives. That's because our internal SOAs are smaller versions of the very same ecosystem that we have seen form on the Web. Getting services adopted and used in the enterprise has been entirely too hard up until now and even many companies out on the Web are falling short of in terms of applying the latest low-barrier, viral distribution techniques for success and uptake.

• SEO, analytics, page views are all challenged by the mashup model. Just like Ajax and Flash, mashups turn single Web pages into entire applications and all three of these Web application models have been slow to address some of the more important models and monetization strategies that power business on the Web. There is ample room for companies that let mashup creators address the loss of these important aspects of Web usage.

As I read through this list, it's a clear that I've tried to address both consumer and enterprise mashups, two very different beasts with a somewhat different audience. I say somewhat different since the consumerization of the enterprise as younger workers bring their Web 2.0 skills and habits to work has already begun. For now however, it's seems clear that whatever the adoption speed, mashups are here to stay as one of the most compelling and efficient ways to turn time and money into working software and solve business problems in new and innovative ways.

Mashups are so easy to create that they should be used as a preliminary litmus test for a startup's business model.

Leader vs. Ruler: Which One Are You?

When I was trying to search for "leaders vs. rulers" on Google, I found many references to governments, royalty, and the military, throughout history. But the strange thing is that none of the articles seemed to distinguish between leaders and rulers. As if leaders and rulers are the same kind of people.

They are not.

Leaders

Last week I was reading the book Tribes, by Seth Godin. In his book Seth says that never in history has it been so easy for anyone to be a leader. These days, with the use of social media, each of us is able to attract our own followers. And on Twitter, this is exactly what we're doing (quite literally). Seth explains that a crowd becomes a tribe when it has a leader that the people are following out of their own free will. And the interesting thing is that people can follow different leaders for different causes.

In software projects it is the same. Some people can take the lead on an architectural level, while some have the lead on a functional level. Still others may be the first ones to turn to when people need advice about tools or processes. A complex system does not need a single leader. In fact, I believe a cross-functional team functions best when it has multiple leaders, each with his own area(s) of interest.

Rulers

In social systems the rulers are of an entirely different breed. While leaders use the power of attraction to convince people what to do, rulers use the power of authority to tell people what to do. Ruling people's lives is the very purpose of the ruler's job. With ruling comes law-making, enforcement and sanctioning, also called the trias politica (legislature, executive, judiciary).

Unfortunately, rulers have gotten a bit of a bad name over the centuries. (Much of it deserved, by the way.) But ruling isn't all that bad. Laws, enforcement and sanctions are necessary evils, and in many social systems rulers can peacefully co-exist with leaders. For example: in any football (or soccer) match you will find leaders (one in each team) and rulers (the referees). They all play their parts in making the game work for everyone.

Are managers rulers?

There's no doubt in my mind that managers are rulers. They are (usually) the only ones with the authority to hire and fire people, and to place them in (or remove them from) teams or departments. They are able to tell people what software to use, what clothes to wear, and how much to pay for a place at the parking lot.

Are managers leaders?

This is a more interesting question. Lots of management book have been trying hard to turn managers into leaders. The last one I read was Good to Great, by Jim Collins. In his book Jim listed a 5-level hierarchy:

• Level 5 Executive: Builds enduring greatness through a paradoxical blend of personal humility and professional will.

• Level 4 Effective Leader: Catalyzes commitment to and vigorous pursuit of a clear and compelling vision, stimulating higher performance standards.

• Level 3 Manager: Organizes people and resources toward the effective and efficient pursuit of pre-determined objectives.

• Level 2 Contributing Team Member: Contributes individual capabilities to the achievement of group objectives and works effectively with others in a group setting.

• Level 1 Highly Capable Individual: Makes productive contributions through talent, knowledge, skills, and good work habits.

The problem I have with Jim's hierarchy is that it suggests a linear progression to "higher" levels (where a leader is on a "higher" level than a manager). This doesn't fit with my observations of how social networks operate.

In a software project, or any other social network, there can be many leaders, each with his or her own goals and desires. Some are taking initiatives for better architectures, some are leading the way to better user interface design, and some are guiding their followers towards better customer service, better processes, better software tools, or better coffee.

To be a leader is not the next step for managers
It is the manager's job to give room to leaders

There are thousands of leaders on Twitter, and they all have their own huge numbers of followers. But who are the managers of Twitter? Only Evan Williams, Biz Stone and Jack Dorsey are. It's their platform. It's their game. They are the referees, making the laws, enforcing them, and sanctioning, while thousands of leaders and tribes are running around trying to score.

Sure, it's ok when managers are trying to be leaders. Nothing wrong with that. Evan, Biz and Jack have a large number of followers themselves too. But they don't have the largest tribes.

Managers are on top of things, but they are not on top.

Rulers don't need to have the largest tribes themselves. Being a great ruler is hard enough already. If you think you need to be a great leader too, you're just making it hard for yourself. Referees contribute to great football/soccer games by being great rulers. They don't attempt to lead. It's not their job. They are in charge, but they are not the ones with the biggest egos.

In his presentation Step Back from Chaos Jonathan Whitty shows that managers are often not the hubs in a social network. It's the informal leaders in a network through which most of the communication flows. It's the managers' job to make sure that leadership is cultivated, and that the emerging leaders are following the rules.

So, you can be a leader, or you can be a ruler. And if you're exceptionally talented, perhaps you can be both.

Which one will you be?

By Jurgen Appelo

What's Really Behind The Talent Gap

It's been a long-running complaint that there aren't enough young people entering the IT field. But judging by the list of experience and skills some employers demand from IT job candidates, you have to wonder if young people just starting out their careers even have a shot at being hired.

Employers aren't just looking for folks with technical skills, they're seeking strong communication ability, business know-how, vertical industry background -- and, in many cases, hands-on experience with a variety of specific technologies and track records of successful deployments. It's one thing to seek the "full package" from someone who's been in the field for years, but much more difficult to find that in people newer to the profession.

So what does that mean? If there really is a shortage of the "full-package" people you're looking for, as employers you've got to be willing to help develop those folks. But apparently, many employers aren't willing to do that. Many companies just don't have the time, money, resources, patience, or vision to cultivate future talent. So, they'll look outside their organizations for ways to bring in "new" people quickly. Or they'll outsource. Or they'll seek foreign workers with H-1B visas. The problem with all of that is this: Often those people don't have all the "right stuff," either.

There's a big gap in what's going on. There's a mismatch in the demand for talent many IT organizations are seeking -- and the degree to which these companies are providing the appropriate training and career development opportunities to build up their bench strength internally. Plus, when it comes to younger folks entering the field, there also are disconnects between what many universities are offering to help these students "align business with technology" with what employers expect from tech workers today. Universities are slow to adapt.

What is your organization doing to nurture its IT talent?

How to Mitigate the Urgent to Focus on the Important

Reading good books, magazines, journals or simply the newspapers in the past has been a very important aspect of my learning life. These days most of the time allotted to reading is when there is a power outage during the daylight hours of the weekend, when there is nothing else to do or on in the nights if there is no access to the internet. However although there has been a deterioration in my reading habits, browsing on the internet has become a replacement. Whether it is good or bad I do spend a lot of time on the internet doing researches, etc. Recently on one of my browsing session on time management I stumbled on an article written by Gina Trapani which caught my attention. It has some interesting facts which I would like to share with you.

Busy people have two options when they decide how their workdays will go: they can choose to be reactive to urgent demands on their time, or proactive about focusing on what they decide is important. The only way to actually get things done is to mitigate the urgent to work on the important.

Let's differentiate between what I call urgent and important.

Urgent tasks include things like that frantic email that needs a response RIGHT NOW; a sudden request that seems like it'll only take two minutes but often ends up taking an hour; a report you've got to write up before a meeting. More often than not "the urgent" is putting out fires, or busywork, or tasks that you'd rather do first because they're less intimidating than your current project list.

Urgent tasks are usually short-term and we're drawn to them because they keep us busy and make us feel needed. (If we're busy people, we must be important people.)

But dealing with a constant stream of urgent tasks leaves you wrung out at the end of the day, wondering where all the time went, staring at the undone actual work you've got to complete.

On the flip side, important work moves you and your business towards your goals. The important stuff doesn't give us that same shot of adrenaline that the urgent requests do. It can involve thinking out long-term goals, being honest about where you are and want to be, and just doing plain hard work that feels boring and tedious. On a personal level, important stuff may include making time to get to the gym every day. On a business level, important stuff may be devising your yearly plan, breaking it down into quarterly and monthly deliverables, and evaluating your current performance against last year's plan. (Doesn't the mere thought of going to the gym and deciding on this year's goals make you want to check your email? Still, that's the work that will help you meet your goals.)

If your workplace encourages that frantic vibe of headless-chicken running and constant urgency, it can feel impossible to focus on what's important versus what's urgent. Still, an awareness of the difference and a few simple techniques can help.

Choose three important tasks to complete each day. Write them down on a slip of paper and keep it visible on your desk. When you have a moment, instead of checking your email, look at the slip, and work on an item. Keep the list to just three, and see how many you can complete.

Turn off your email client. Shut down Outlook, turn off new email notifications on your BlackBerry, do whatever you have to do to muffle the interruption of email. When you decide to work on one of your important tasks, give yourself an hour at least of uninterrupted time to complete it. If the web is too much of a temptation, disconnect your computer from the Internet for that hour.

Set up a weekly 20-minute meeting with yourself. Put it on your calendar, and don't book over it — treat it with the same respect you'd treat a meeting with your boss. If you don't have an office door or you work in an open area that's constantly busy, book a conference room for your meeting. Go there to be alone. Bring your project list, to-do list, and calendar, and spend the time reviewing what you finished that past week, and what you want to get done the following week. This is a great time to choose your daily three important tasks. Productivity author David Allen refers to this as the "weekly review," and it's one of the most effective ways to be mindful about how you're spending your time.

Be The Change:

Put in practice one of the three tips in the article above.

Greased Lightbox

→←+-↻

Loading image

Click anywhere to cancel

Image unavailable

What Oracle sees in Sun Microsystems

Over the past 13 years, Sun Microsystems' Java language has become one of the computer industry's best known brands, and under appreciated assets.

The tension wasn't lost on Sun's new owner, Oracle, which on Apr. 20 said it will purchase Silicon Valley pioneer Sun for $7.4 billion in cash. If Oracle has its way, Java will emerge not only as a strong revenue source but also a key component of plans to keep customers loyal for years to come.

During a conference call with analysts on Apr. 20, Oracle CEO Larry Ellison called Java "the single most important software asset we have ever acquired." It's a bold statement from a chief executive who has spent in excess of $40 billion to buy more than 50 software companies since 2005.

Powering PCs and Cell Phones

Ellison is willing to make that call because the Java programming language, widely used to write much of the world's business software, is a key ingredient in Oracle's recipe for ensuring the many products it has already acquired work smoothly together. Java also runs on 800 million PCs and 2.1 billion mobile phones. PC makers and cell-phone vendors, including Nokia, pay royalties to license the software.

"When you look at those numbers, they're enormous," Citigroup analyst Brent Thill says of Java's potential. "Oracle looks at this and says, 'This could be a $1 billion business.' Yet Java supplied just $220 million of Sun's $13.9 billion in 2008 revenue. "Java is the most valuable brand in software that has no value," says Joshua Greenbaum, principal of industry analysis firm Enterprise Applications Consulting.

Oracle hopes to wring value from the deal in part by cutting costs to make Sun's hardware and software businesses profitable. Oracle also wants to sell Sun's Solaris operating system and servers in tandem with its market-leading database software. Citigroup's Thill estimates Oracle could cut between 40% and 70% of Sun's roughly 33,000 employees. Excluding restructuring costs, Oracle expects Sun to add $1.5 billion in profit during the first year after the acquisition closes this summer, and another $2 billion the following year. Oracle executives declined to say how many jobs would be eliminated.

Buying Sun gives Oracle access to popular software it can wield against its competitors. In addition to Java, Oracle gains Solaris, widely used in industries including telecom and finance. Oracle also picks up the MySQL database, which is available free under an open-source licensing arrangement, and could help Oracle check sales of Microsoft's SQL Server database to smaller companies. "Sun is not a well-managed company," says one industry executive familiar with its business. "But it does have assets that can become lethal weapons for the one owning them."

Little Hardware Experience

But to gain those assets, Oracle also has to take on a hardware business, something it has little experience running. Ellison will have to make a success of Sun's server business, which has been losing money. Oracle has made its own forays into the hardware business, striking a deal with Hewlett-Packard last year to produce servers designed to provide a performance boost to Oracle databases that run on them.

Oracle executives suggested during the conference call that they could sell specially tuned packages of Sun hardware and Oracle software in industries including telecom, retail, and banking.

But Oracle's 46% operating profit margins, among the industry's highest, will no doubt be squeezed by the addition of Sun's server business. "There are far more challenges here than opportunities," says James Staten, an analyst at Forrester Research. Some Wall Street and industry analysts suggested Oracle sell Sun's hardware business to help pay for the software with more long-term value.

In that regard, Java could be a trump card for Ellison. For one, Oracle can throw its large and effective sales force at Java, and contracts with Nokia and other handset vendors are coming due for renewal, says one source close to Oracle.

A Counterweight to Microsoft

Second, Java is key to a set of Oracle business applications called Fusion, designed to stitch together the array of programs Oracle has scooped up through its acquisition binge. Controlling the software in house could help Oracle assure customers of a smooth transition from older products to new ones. And owning Java gives Oracle a counterweight to Microsoft as it tries to convince more developers to incorporate its database, middleware, and other software into their products.

Oracle is expected to generate more than half of its estimated $23.1 billion in 2009 sales from technical support and "maintenance" of products its customers have already licensed. Those support contracts carry profit margins of about 90%. Controlling Java "is all about future maintenance streams," says Citigroup's Thill. "This will create stickier lock-in for the Oracle installed base."

One company that notably held its fire about the Oracle-Sun deal is IBM, which also heavily relies on Java. Oracle's bid for Sun edged out IBM's $7 billion offer, which fell apart earlier this month. While Oracle could use the acquisition to make it harder for Big Blue to develop software using Java, a person close to IBM says Oracle would be better served using Java as a bulwark against Microsoft, whose .Net technology competes with Java. "Both IBM and Oracle need, more than anything else, a healthy Java market," says consultant Greenbaum. Now that IBM has taken a pass, Java's fate lies largely in Oracle's hands.

Don't Graduate with the Wrong Degree

Let’s pretend you’re a senior liberal arts major, and the only reason you chose liberal arts in the first place is because you didn’t really know what else to major in. Now you wish you could go back and major in business and work in sales instead.

Does this mean you’re doomed to a career you don’t care about? No.

Here are some ways to apply your wrong degree to the right career:

Focus on Transferable Skills

There are the skills you can easily transfer from one job or career to another. Your transferable skills might include research and writing skills from typing up all those reports.

Supplement Your Wrong Degree with the Right Experience

Majoring in liberal arts, you may not have considered an internship in sales. Put your knowledge to use and gain experience by netting internships at a small business or volunteering to write material for a sales organization.

Don’t Let it Hold You Back

There’s really no such thing as a wrong degree. With the right experience, anyone can transition to a new career or profession. If going back to school is an option, start by searching for schools and degree programs for the career you’ve always wanted!

It’s Never Too Late To Go Back to School

You might be graduated with a liberal arts degree, but that doesn’t mean you can’t return to school to pursue your passion. Degree programs are more convenient than ever.

Ten ways of thinking that can fell IT leaders

Is your thinking impeding your progress? This is a significant problem for an individual and a much more serious one if you’re in charge of an IT department. As the CIO or an IT Director, you steer a ship of technology and people and one hopes that your maps are up to date, your compass is true, and you know how to get to the destination most efficiently.

I see a lot of organizations and people as a consultant. I often encounter situations where I can’t help but feel that an IT department could be a runaway success within its organization if it weren’t for the beliefs that their leader seems to hold. I want to share with you a small collection of such limiting beliefs. There are ten in this list but I could have just as easily added another twenty.

Can you recognize any that plague your organization?

1. The business should identify its technology needs

Think about this very carefully: Who is more valuable to you, someone who knows how to tighten a bolt or someone who knows which bolt to tighten? We’re a knowledge economy and knowing what to do is much more valuable than being able to follow instructions.

If you believe that the onus is on the business to identify technology needs, you’re wrong. You need the business to identify business issues, opportunities, and priorities, and then you and your people have to come up with a way of addressing them from the technology perspective. (Better still, you can elevate your personal positioning by delving deeper into the business content and strategy, but that’s a different story). You and your department are the experts in technology, not the CFO or the Director of Marketing. If you see your department’s raison d’etre as merely implementing and maintaining the technology that business chooses, you position yourself as the guy who tightens bolts. IT departments that fall into this trap get outsourced.

2. We are a fast-paced organization

I have yet to discover an environment that doesn’t claim to be fast-paced. I no longer know what that means. What’s important, though, is how this assertion impacts the people within. If you’re told for a while that you’re incredibly busy, you tend to start believing that it must be so, and your capacity decreases. If you’re told that there’s no time to think, you tend to sacrifice quality of decisions for the sake of speed, even though there may be plenty of time to plan and execute. The net result is an organization with a high rate of project failures, too focused on firefighting and too “busy” to think strategically and identify work that’s truly important.

You can never be too busy for the important stuff if you get your priorities right.

3. We are under-resourced

This is a universal complaint and I’ve met plenty of IT executives that resort to it. It happens in organizations where there are staff members who can’t coherently explain what it is that they do, where there are ten project managers for every project, where every trivial thing involves days of meetings, and where out of every ten projects going at any time, eight have no business value.

You can never have enough time, staff or money if your priority system is out of order. The key is in using the resources you have in such a way that they produce the best ROI possible.

4. Show me the money! For a project to be approved, it needs to save costs or generate revenues.

I know an organization that spent five or six years in cost-cutting mode. If you wanted to buy a pencil sharpener, you had to get a nod from the CFO. After years of this drought, cash finally became available and the company started to look for growth. There was a problem, though, in that the company’s management at all levels had become unable to think in terms of growth. Their ability to innovate all but died and when bold and novel market moves were appropriate, they only managed to come up with meek, low-cost low-value initiatives. Even their ability to plan prudently was affected and they continually understaffed projects despite having access to necessary funding.

If you merely concentrate on the financial side of costs and benefits and require that all projects have a positive immediate ROI to be pursued, you’re killing innovation in your organization. Think about it. How innovative would you want to be if every suggestion you make is immediately evaluated in respect to financial benefit?

5. In difficult times, we must cut costs

Prudent financial management is a must at all times, good and bad. But consider this - it’s impossible to become successful by pinching pennies. It just doesn’t happen.

The best value generated by an IT department today does not lie in trivial and often mindless cost-cutting but in innovation, business alignment and strategic thinking. Today more than ever, your organization needs new ideas, bold thinking, full understanding of business priorities and the ability to think about the needs of tomorrow, not the adversity of today. Will you be ready for the recovery? I predict that most organizations will be slow out of the starting gate.

As the IT leader, you must invest - not cut - time, money, executive support into business critical projects, while completely abandoning projects that are no longer relevant. You must constantly challenge your people to critically examine the ways you do business and improve them. They don’t call you a leader for nothing.

6. We don’t need expensive outside help

Tiger Woods is the world’s #1 golf player and one of the most famous sports personalities overall. Since 1995, he competed in 53 major championships, of which he won 14 and finished in the Top 10 another 16 times. His drive is so powerful that many top golf courses are adding yardage, the practice known as “Tiger-proofing.” He is a remarkable athlete by all accounts.

What can he learn from anybody? Yet Tiger Woods has a coach. So does Lance Armstrong. So did Magic Johnson. Great in their game, they have or had someone to help them to become outstanding.

This is a stark contrast to some IT leaders who don’t believe in calling on the leading outside expertise when necessary. Instead, they subscribe to relying solely on the internal resources, typically for the sake of some nominal “savings.” What they miss they would not know because they are so focused on their small world, unaware of what other people and organizations are achieving. Had Earvin Johnson had this attitude, we would have never heard of Magic Johnson or witnessed his brilliance.

External perspective and expertise is critical (I am not talking here of staff augmentation) to growing your organization and bringing it to the next level. Is your strategy right or are you going fast in a wrong direction? Are your people realizing their full potential? How do you instill the spirit of innovation?

Strong leaders actively seek the best help they can get. I have just acquired a new client, a well-known business organization in Perth, whose COO wanted to roll out a project management methodology and grow organizational project management competency. He did not just send his people to one of the ubiquitous canned public courses or tell them to download some templates from the Internet, he chose to talk to me.

If Tiger Woods has a coach, why don’t you?

7. Our challenges can be resolved by implementing ITIL

I am not picking on ITIL; you can substitute COBIT, PRINCE, Zachman framework, Agile development, TQM, TPS, Six Sigma, Nine Omega or another methodology du jour. There is nothing wrong with any of these; in fact they are useful when applied as intended. The problem is in misapplication, which is increasingly common.

There is a tendency in many people placed in a leadership position to look for the proverbial silver bullet of a methodology that would miraculously fix all of the existing problems. Unfortunately, this approach is as successful as attempting to treat all human ailments with but a small assortment of medicines and without any diagnosis.

Building a truly successful IT organization is not an easy task. It requires strong leadership, intelligence, some hard work, determination and, often, some serious chutzpah. The allure of an “easy” methodology is understandable.

One very good executive asked me if it was a good idea to implement Six Sigma and Lean in his public sector organization (a sponsor came forward to offset the implementation costs). I honestly offered the only possible answer: “I don’t know.” (Imagine asking a doctor who does not know you whether you should start taking antibiotics.)

Instead of jumping on the bandwagon, envisage what you would like your department to become, identify the gaps that need to be bridged and start working on it. Get outside help if you need to. Once you are informed, feel free to implement the best demonstrated practices, such as ITIL, modifying them as appropriate for your organization.

8. Our people are our main asset

This is one of those fallacies that gets repeated so often that it is perceived as an axiom.

A few years ago, back in my corporate days, I worked with a senior executive who evidently had been hired in error. With too many shortcomings to list, he was considered “too expensive to fire” and hence, continued to influence the course of his department for years past his “due date,” initiating misguided projects, letting some good people go, and missing great business opportunities. The cost of such a miscreant to the organization far outweighs the separation costs.

Not everyone in your department is great or even good enough. The main asset of every organization is its BEST people, not every warm body on the payroll. But too often, IT leaders aren’t even sure what their people do and whether they are good at it.

Now that many talented people have been laid off, it’s a good time to strengthen your team. Get rid of the deadweight, attract the bright stars.

9. Hiring talent is easy today

Do you remember the IT talent gap? Yes, the global battle for talent that everyone seemed to talk about at the turn of the century and then again a year or two ago? The sources which sounded alarmed at the magnitude of the problem are suspiciously silent today. A year ago, I wrote an article on the issue in which I suggested that the problem in hiring the talent is not so much in its shortage but in the way we go about the hiring. Today, I am saying that the problem has not gone away, despite the awful job market reports and wide availability of good people. Hiring managers in organizations are none the wiser, using the same dismal methods that prevented them hiring the right people when the economy was booming.

Here are just five out of perhaps dozens of pointers:

• Do not outsource pre-selection to low-paid people who know nothing about your organization, your department and your needs, and very little about IT.

• If you want talent, look for talent and passion, not for conformity (e.g., 75 years experience in working with RDD 719991 ver. 7.4). * Highly talented people who you’d want to hire are usually not unemployed.

• Compromise: most skills can be easily taught, but curiosity and drive are not as easy to instill.

• Hire people who are better than you, who did not follow the same career path as you, and who don’t look like you.

10. It’s okay to make mistakes

Ebay announced that it sold StumbleUpon, an internet recommendation engine, purchased a couple of years ago for $75 million. It did not work out, a mistake was made, and now the management decided to call a spade a spade, divest, and move on.

The corporate world is often criticized for not allowing employees to fail, ever. If people are not allowed to fail, what incentive is there to innovate, take prudent risks, and disturb the safe harbor of status quo? This is true and is especially important in the world of IT, where experimentation, “tinkering,” and doing things we have not done before is a norm. As IT leaders, we must allow mistakes to be made and even celebrate them from time to time.

But not all mistakes are made equal; some are made repeatedly out of sloth, negligence or incompetence. There is no excuse for these mistakes that I can think of. Surprisingly, many IT leaders prefer not to take decisive measures and leave employee performance problems unresolved or simply mothball them until the “performance review time,” when, frankly, it is too late. This is simply abdication of managerial responsibilities which cannot be condoned.

I have known an IT Director, whose network administrator had a more-than-annoying habit of playing with router configurations during the busiest time of the day, causing, on several occasions, the network to go down. The IT Director resented the very notion of confronting the issue until yet another experiment caused a particularly nasty downtime. He finally had to confront the issue, but of a different nature: finding another job after having been let go.

Time to Protect Your Best Customers

Studies of recessions dating to the 1920’s prove that marketing aggressively in a down economy can increase market share substantially more than during good times.

A top best practice in tough times is fiercely protecting your loyal customers, making Customer Retention Marketing more important today than ever. Put your customers at the heart of your business, and you build a competitive advantage that continues to grow after the economy recovers. Unfortunately, many marketers limit themselves to an outdated, simplistic, and less effective CRM approach. It’s time to usher in a 21st Century CRM that utilizes the most powerful strategies and tools available, and achieves great success in a weak marketplace.

Out with the Old CRM Approach

Too often CRM programs consist only of outbound e-mail or direct mail. As more consumers become engaged with alternative communication channels, and less with e-mail, now is the time to upgrade CRM. For example, young people seldom use e-mail unless they have to, instead relying on social media (e.g., Facebook), text messaging or IM. (“You sent me an e-mail? I never check my e-mail,” say my teenage and college-age daughters.)

Keep the CRM mainstays — e-mail and direct mail — that have worked well, but augment your efforts by exploiting digital and social marketing opportunities, like digital tools (IM, widgets, etc.), mobile, and social media. The new CRM mix has many concurrent elements, such as social communities needing an e-mail blast to update members, or some e-mail requiring a social media approach that engages more personally.

Welcome to 21st Century CRM

Here are 7 ways to seize the tremendous opportunity of 21st century CRM:

Think CMR. The term “Customer Managed Relationships (CMR)” was coined to recognize that consumers exercise more control of marketing interactions. Studies indicate the more control you cede — letting consumers select their preferred communication channels, content they want, how frequently they hear from you — the more likely they will opt in, interact, engage, etc.
Example: Centrum Healthy Habits lets consumers select the frequency of communications they receive.

Detach & distribute. Don’t limit consumer interaction with your brand to one channel. Provide portable content, tools and experiences that are multi-channel and travel with consumers wherever they go (e.g., mobile). Place your content and tools on 3rd party sites. Develop communications across e-mail, mobile, social, etc. that let consumers subscribe in multiple ways.
Example: Kraft Foods’ iPhone application provides mobile recipes and tips.

Practice “Marketing as Service”. Deliver content and tools that consumers see as providing real value and relevance. Communicate with a helpful, customer-centric voice to deliver content or tools that deeply engage, provide a tangible value-add, and build an ongoing relationship.
Example: Hallmark Crown Rewards offers calendar reminders for most occasions.

Be “social,” a “community organizer”. Create community areas on your site and on social media destinations (e.g., Facebook) where your target congregates, to facilitate connections sharing with one another. Actively participate through community content and interactions, like engaging customers in product discussions. Enrich the experience by creating a dialogue inviting feedback or input.

Example: Nestle Very Best Baking allows bakers to share recipes.

Measure more than 1 to 1. Continue comparing sales of a control group of customers that don’t receive your CRM program with those who do to quantify the incremental value of the program. But also track the Word of Mouth, Viral and Advocacy effect, through quantitative social media measurement tools and qualitative surveys.

Example: Nuts Online tracked the impact of a 2007 viral campaign that saved the CBS Show Jericho.

Beyond Customers. Expand CRM to incorporate key constituencies — employees, distributors, retailers, professional gatekeepers (e.g., physicians for pharma). Create programs that build stronger relationships with your organization’s important groups, and link them to increase CRM’s performance, such as when a retail consumer receives your CRM and subsequently sees a related in-store display.

Example: Royal Caribbean offers programs to both travel agents and consumers.

Identify Advocacy Potential. Identify your most valuable and loyal customers via your database or during opt-in registration. Treat your most valuable customers like VIPs. Invite loyals to be advocates or ask their propensity for word-of-mouth. Identify influentials in social media discussions and empower them as potential advocates, too. Time your CRM contacts for when customers are most passionate about your products.

Example: Karmaloop enlisted customers in its “Street Team” with unique rep codes to pass along to friends — the customer got a discount, the rep a commission, and the company over $700M in sales.

In this challenging marketing environment, these 7 opportunities will elevate your CRM to a 21st Century caliber, and ensure you achieve the best results possible.

Expresss your opinion, comment below.



By Michael Maher

Five trends that will shape business technology in 2009

The year 2009 will be challenging for CIOs. Here’s how to play your hand.

When downturns hit, there is a certain inevitability to their impact on IT. Declining profits will place tremendous pressure on IT budgets in most sectors and regions. CIOs will be called on to rationalize projects, downsize organizations, renegotiate contracts, and seek out other cost-reduction opportunities.

Much has changed, however, since the last big downturn, in 2001: technology budgets are larger, businesses have automated more processes, employees make greater use of tech-based productivity tools, and e-commerce has moved to the core of day-to-day operations. At the same time, IT organizations have established better mechanisms to govern IT decision making and have consolidated local IT operations to cut costs.

Taken together, this combination of cost pressures and IT organizations that are leaner, larger, and more vital to company goals will have new implications for business technology in 2009. Here’s what may be in store.

IT and corporate finance converge

The year 2009 will be a tipping point for the CFO’s involvement with IT. Large businesses have hundreds of millions or even billions of dollars locked up in their IT organizations—including data center facilities, systems assets, and organizational capabilities built over time. In a world where capital is at a premium, CFOs will seek to use IT assets as a lever to generate cash. They may sign outsourcing deals that include a bigger financing aspect, such as having IT service providers make a large up-front payment in return for higher margins over the course of a contract. They may sell and lease back hard assets, such as data center facilities. They may place favorable vendor financing at the core of hardware and software purchasing decisions, as many companies in heavy industry do when they buy industrial equipment and as telcos have done for years. Successful CIOs will give the senior-management team practical ideas on how to optimize cash.

Tension around IT budgets increases

Since 2001, IT capabilities have become ever more strategically important for most sectors. Yet IT budgets in many organizations will come under tremendous pressure in 2009, reducing investment for new business capabilities. Internal competition for rationed IT resources will become especially fierce as senior executives see access to them as critical to the success of their business units and their careers. Successful CIOs will have to position themselves as honest brokers, pushing hard to evaluate IT investments in a fact-based way yet avoiding any perception of being allied with one business unit or another.

The “last” IT project?

While it’s clear that technological competence is critical in most industries, the variation in returns on IT investments is daunting. In retailing, for example, a CFO knows with some precision what an additional location will cost and how much revenue it is likely to generate. In contrast, an IT project’s total cost could be off by an entire order of magnitude and its value either minimal or game changing. Senior executives at some organizations that have used IT less successfully in the past will probably throw up their hands and shut off all discretionary IT projects for the duration of the downturn. Naturally, this situation will challenge CIOs. The most effective course will be to explain what it would take to improve the value equation for IT investments.

Regulators demand more from IT

Government scrutiny of business will intensify in many developed countries. Already, in the United States, the Office of the Comptroller of the Currency weighs in on the resiliency of banking systems, the Food and Drug Administration (FDA) requires that many pharmaceutical systems be “validated,” and Sarbanes–Oxley drives decisions about accounting systems in every industry. In the future, policy makers and regulators will probably demand that IT systems capture more and better data in order to gain greater insight into and control over how banks manage risk, pharma companies manage drugs, and industrial companies affect the environment. Government officials also will monitor many legal and business rules more closely to ensure compliance with mandates. Successful CIOs should enhance their relationships with internal legal and corporate-affairs teams and be prepared to engage productively with regulators. They will need to seek solutions that meet government mandates at manageable cost and with minimal disruption.

The offshoring and outsourcing landscape shifts

A decade ago, how many CIOs at Fortune 100 corporations would have guessed that Indian companies might now be among their largest and most strategic technology vendors? Just as the 2001 downturn led to a surge in offshoring, the 2008 downturn will also have far-reaching effects. A shake-up in the vendor landscape will likely follow the huge capacity increases of recent years, the current downward pressure on aggregate demand, and massive uncertainty in currency markets. Adding to the pressures are the strategic, government-sponsored initiatives launched by China and other nations to grab market share. Major mergers are more likely than not. New entrants will grow rapidly and some players could experience significant reverses. Successful CIOs will manage their vendor relationships as a portfolio so they will be well positioned as new winners evolve. CIOs will also need to be vigilant about how to manage transitions created by the consolidation or weakness of some service providers.

Major, often unexpected, changes will directly affect IT organizations in 2009. The successful CIOs will be those who execute well, expand their influence within the enterprise, and, perhaps, are a little bit lucky.

Stefan Spang

How to Develop Your Vision - Part 4

Here's the fourth part of Developing Your Vision...

Unfortunately, it is impractical to expect every department-head to understand the entire vision. As a matter of fact, it is virtually impossible because it is likely that they do not understand the other disciplines well enough, or have enough access to information. However, a good CEO makes sure each department-head has a complete understanding of their slice of the vision and how it is phased in properly, over time, with the other departments. This can sometimes be done, by creating interlocking goals or end dates that are one or more quarters away. For example, customer-service will hire a new manager when sales hit 20 new customers.

A vision is important because it is what unifies all of the resources on a single 'objective' - which ultimately is a single position in the marketplace. This position must include virtually all product-factors recognizable by a sophisticated buyer in the market, as well as all the variables that make up the complex structure of the organization to create, deliver and service that product. Each day, a CEO will use the vision to measure decisions against, each day the VP of Engineering should be making decisions consistent with his or her slice of the vision, and each day all key management players should be doing the same. If you have someone measuring their daily decisions against their modus operandi at a former company, or just their favorite way of doing things, then odds are you have a personnel problem that needs to be addressed. This is a common problem because human nature dictates that we to do it the way we always have (the easiest way); as opposed to really thinking about how this situation may be different. In my experience, it takes a new CEO four to eight weeks of full-time work to develop a complete vision for the company. This will vary greatly, depending on the complexity of the company, market and product involved.

Vision development must include time spent with customers, time spent with all key employees, and lots of research to validate the theories that are being used to make decisions.

Tomorrow's lesson will go over communicating your vision...

How to Develop Your Vision - Part 3

How to Develop Your Vision - Part 2

How to Develop Your Vision - Part 1