Information Technology Strategy

This Is Your Opportunity

Friday, February 6, 2009 by Michael Kiffmeyer

I read today that unemployment has risen to 7.6%. Yes, its official – we are in a recession. However, that does not mean there isn’t opportunity because there is. If everyone believed everything the press is saying our economy does not have a chance and the United States is going to cease to exist.

I also read today that the U.S. government is going to re-visit its parameters for H-1B Visas because they are being used by recruiting body shops rather than giving foreign nationals the real opportunity that they seek. This means that application developers and specialist are going to be able to make up ground that they have lost to foreign nationals in the past.

My suggestion is for developers to increase their skill-set now before the economy begins to get worse. Information technology consulting has never been a steady business it always has had peaks and valleys. When the economy is good projects are plentiful. When it starts to decline projects usually come to a grinding halt. But is you have multiple skills it decrease your odds of becoming a statistic.

Organizations try to do more and more internally rather than outsource it when the economy begins to falter. The more skills a person has the better chances one has to stay employed. This holds true for IT staffing, development and consulting. Additionally, when a developer or infrastructure architect can show an organization how to safe time, investment and people through the implementation of their solution they will endear themselves to that particular organization.

Good information technology strategy can more than pay for itself in this economy. Organizations everywhere are dependent on technology and they need processes to become dynamically automated so they can accomplish more with less while the move towards models of efficiency that will contribute to the productivity of the organization.

Make it your mission to learn more applications and methodologies that can greatly increase the productivity of any company. To do this is to build value for the organization and you by ensuring there will always be a job for those that are willing to innovate and create a better way.

This is your opportunity. Make it happen!

Tell Someone.

Tuesday, November 25, 2008 by Jeff Welsh

I just finished up a meeting where we were talking about information technology strategy. During the conversation that person told me she had talked with one of our common customers. At that time, she didn’t realize we had a common customer, but the customer started talking about how pleased he was with our IT Wellness check.

It’s really cool to have someone talk about one of our IT strategy services in an unsolicited manner. Too many times, we hear about negative experiences. So if one of your vendors does a great job for you, tell someone.

Death of the CIO?

Tuesday, November 4, 2008 by Aaron Whittenberger

Rob Preston, VP and Editor in Chief of Information Week, looks at the two sides of the question of the future importance of the CIO role in business. This affects more than Cincinnati IT Jobs or the Southwest Ohio Information Technology arena, but across America and the globe.

He sites many blogs, articles and books in his article that stand on one side of the fence or the other. The central piece centering around Nicholas Carr who in his many articles and books promote the idea that “IT Does Not Matter” and Ian Campbell who call for the death of the CIO role in American business within five years.

“All this chatter makes for lively blogs and columns, even if most of the pundits end up pulling back from their shock statements. But there's also some truth underneath the bluster. Business technology pros, academics, consultants, analysts, and others see a confluence of events and trends that are either marginalizing CIOs or subjecting them to intense scrutiny like never before.” states Rob Preston. He compares these statements to those who predicted the Dow Jones Industrial Average would soar over 30,000 by this time.

The article is a very interesting read and invokes intense thought on the subject. As to whether the role of the CIO will be dead in five years, I cannot put it better than Rob; “Now, the CIO profession is anything but dead for those eager to take on the above challenges. In fact, the demands of globalization and business reinvention will elevate the sharpest CIOs to business process owners, master integrators, and ultimately trusted innovators. The CIO position has never--never--been more critical.”

Today’s fast-paced, ever changing business environment does not lend itself to the old “reductionist” IT model. Every business organization, no matter what the size, will need a leader at the strategic level to ensure that the Information Technology Strategy supports the business strategic goals and initiatives of the organization. Whether the title is CIO, IT Director, Chief Integration Officer, IT Manager or CEO; the role is essential to the organization.

The Next President Will Have Full Plate, Including IT

Friday, October 24, 2008 by Aaron Whittenberger

The next President of the United States of America will have a full plate to contend with. Along with the issues that have been getting top bill during the presidential debates and campaign—securing the financial future of America, rising health care costs and the energy crisis; he will have several Information Technology Strategy initiatives to deal with.

According to an article by Jon Oltsik, Senior Analyst at the Enterprise Strategy Group, the government is treading water on a number of highly-visible, strategic initiatives like the underfunded Comprehensive National Cyber Security Initiative and the implementation of the 2002 Federal Information Security Management Act. See the article for details on these initiatives.

These initiatives could have far reaching implications on Information Technology Strategy and change IT Infrastructure Management for the federal government and many businesses within America by enforcing new legislative regulations on those businesses. Does this have the ring of Sarbanes-Oxley to you?

Virtual Bench

Friday, August 29, 2008 by Aaron Whittenberger

Many IT Consulting Services companies in Cincinnati maintain a Virtual Bench. What is a Virtual Bench you ask? I am glad you asked. Virtual Bench refers to the idea of being able to call upon, often on short notice, any number of IT Business Application Development professionals that a company has previously employed or worked with in the past.

STAR BASE, Inc. is one of the few IT Services companies in Cincinnati that have actual on staff employees. The problem with maintaining only a virtual bench is that you can call upon that IT professional that you need to fill an IT Staffing need and that professional is not currently available. By employing our IT Business Solutions and Technical Consulting professionals we can ensure that our professionals are always available to service the needs of our clients. This also allows the company to see to the training of our professionals to ensure that they are up to date on the latest technologies and tools of the trade.

A popular Information Technology strategy that companies employ these days is IT Outsourcing of business application development. This strategy allows the company to transfer the cost of IT staff training, among other costs, to the IT Outsourcing Services Company. However if the IT Outsourcing Services Company only maintains a virtual bench, they cannot control the training of their professionals. So if you are considering an IT Outsourcing strategy, make sure that the vendor you choose to supply your business application development professionals maintains an actual on staff bench. This not only helps to ensure the technical and business expertise of the IT staff you will be getting, but it reduces other risks of IT staffing.

Intrapreneur's Ten Commandments

Wednesday, August 20, 2008 by Jeff Welsh

My blog post from the other day got me thinking about my early days in information technology consulting and information technology strategy. Something that has not changed, is for companies to deliver applications for the lowest possible cost. One IT strategy that everyone should be looking at in today’s world is Virtualization.

While I was consulting at P & G one of their IT strategies to lower costs was to move applications from mainframe to midrange systems. I was working on a project called CRP (Continuous Resupply Process). The goal was to not only move to a new platform, but also to streamline the process as well. While reengineering these processes, I remember invoking the eighth commandment quite a bit. So today I thought I would share these “commandments” with you.

1. Come to work each day willing to be fired.
2. Circumvent any order aimed at stopping your dream
3. Do any job needed to make your project work.
4. Find people to help you and work only with the best.
5. Follow your intuition about the people you choose.
6. Work underground as long as you can.
7. Never bet on a race unless you are running it.
8. It's easier to get forgiveness than permission.
9. Be true to goals and realistic about ways to achieve them.
10. Honor your sponsors.

As some background: At that this point in time, P & G was trying to get their internal people to think like entrepreneurs. These “commandments” were developed to help them.

Would-be CIO's

Wednesday, August 13, 2008 by Michael Kiffmeyer

Professional IT practitioners who have aspirations of becoming a CIO need more than technical skills to succeed. Today’s business world requires individuals to have multiple skill-sets to compete by acquiring at least one or two years of non-IT business unit management experience.

Trends the past few years in major organizations have somewhat de-emphasized the formal technology –oriented background and placed the emphasis on professionals that can show they have managed a non-IT business unit. Professional qualifications and competence are still necessary but will not be sufficient in coming years.

There are two significant trends that are affecting CIO’s:

• CIOs need non-I business unit experience to progress in their careers
• CIOs are being given more and more Non-IT duties

Gartner has confirmed from their research that more CEO’s are looking for individuals to run a department other than IT. Those individuals that have had the ERP experience are also at an advantage because it has given them particularly good knowledge across the whole range of activity within the business.

The ability to leverage technology for competitive advantage and to have the ability to innovate new solutions is what organizations are looking for. To do this an individual will need technical and business savvy and have a good comprehension on how technology can assist the outcome of a given solution. Imagine the value this type of professional can bring to any organization that they are a part of?

We recognize this need at STAR BASE, Inc. and offer CIO’s and IT practitioners “thought leadership” that starts with master data management that solves business problems-providing tangible business value and significant ROI. CIO’s of the future will need to consider how information technology strategy, IT infrastructure and application development projects equate back to the mission and the goals of the entire business-

Want to know more? Please visit Tekrati: http://cio.tekrati.com/research/10038/

IT Can’t Run on Fumes!

Saturday, August 2, 2008 by Aaron Whittenberger

InformationWeek ran an article on How CIOs Are Dealing With A Tough Economy. It states that on top of the list of strategies of dealing with today’s tough economic times is holding off on IT staffing increases and delaying IT Infrastructure upgrades.

CIOs are also putting together the Plan B list of projects, efforts and/or areas that can be deferred in case things get worse. Cost-cutting IT Infrastructure upgrades such as voice over IP deployments may get the green light, but more strategic efforts such as data cleansing or server consolidations may have to wait. Some CIOs report that application development “will be maintained as much as possible”, but projects like 3-D system designs will be put on the back burner.

According to a recent InformationWeek survey of 600 business technology executives 40% say they have decreased IT spending this past quarter over their original 2008 budgets.

All is not grim. Even though most business executives surveyed expect IT spending to decline, some CIOs are moving forward with big Information Technology strategic initiatives. CIOs are protecting customer-facing projects and cutting in other areas. They also are looking for ways to invest in technology to gain a competitive advantage over weakened competitors.

Whichever your current Information Technology Strategy, keep in mind that IT cannot run on fumes. It may be possible to delay IT Infrastructure upgrades and IT staffing needs so long that it paralyzes the organization’s ability to be proactive in these difficult economic times.

Mistakes Plague IT Projects

Wednesday, July 30, 2008 by Aaron Whittenberger

A recent CIO.com article states that The Standish Group says that 29 percent of all IT projects are never completed successfully, often because CIOs don't follow standard management processes, don't have the right IT staffing, don't properly assess the risks, or don't take quick enough action to mitigate problems that can grow out of control.

CIO.com has compiled a list of the 14 most common project management mistakes that plague IT business solutions projects:

   IT Staffing Mistakes

     1. Projects lack the right resources with the right skills
     2. Projects lack experience project managers

    Process Mistakes

     3. IT doesn’t follow a standard, repeatable project management process
     4. IT gets hamstrung by too much process
     5. They don’t track changes to scope of the project
     6. They lack up-to-date data about status of projects
     7. They ignore problems

    Planning Mistakes

     8. They don’t take the time to define the scope of the project
     9. They fail to see the dependencies between projects
   10. They don’t consider Murphy’s Law
   11. They give short shrift to change management
   12. Project schedules are incomplete

    Communication Mistakes

   13. IT doesn’t push back on unreasonable deadlines
   14. They don’t communicate well with project sponsors and stakeholders

Actually, common knowledge knows that over half of IT projects fail to complete on time and within budget. From these problems grew the profession of Business Analysis. The International Institute of Business Analysis (IIBA^TM) was chartered in 2004 to promote the profession of Business Analysis and certify its practitioners. They state the most common reason for failures of IT projects is poor requirements definition. Whichever you believe the reasons for failures of IT projects it is evident that CIOs must come up with a better Information Technology strategy to address these issues. I wrote last month on how these two professions work together for the success of IT business solutions projects. The Project Manager (PM) is responsible to see that the project is completed on time and within budget. The Business Analyst (BA) is responsible to see that the project is completed and meets the business requirements defined for the project.
As you can see they both are working toward the same goal…the successful completion of the project. How they define “successful completion” differs a little. It is without doubt that the successful completion of IT business application development projects can be greatly increased by having an experienced PM and an experienced BA assigned to the project. Having experienced, well-skilled PM and BA on the project can resolve all 14 of the common mistakes that plague IT projects above. So if your looking for a new IT Staffing strategy to help your organization, make sure you have plenty of experienced project managers and business analysts on staff to staff all your IT business solutions projects and initiatives.

How Important Are Your Customers?

Thursday, July 24, 2008 by Aaron Whittenberger

A growing trend in American business is the existence of a Chief customer eXperience Officer (CXO). This trend recognizes the importance of customer satisfaction on the success and continued viability of a business. It isn’t that companies all of sudden woke up and said customers are important now, but rather companies are more and more coming to the conclusion that a more focused approach to the customer experience will increase customer satisfaction; and thereby increasing revenue.

The CXO is responsible for the customer experience across all channels. This may include customer service, sales, marketing, public communications, IT business solutions and customer-facing projects among other areas of the organization. Ann All of IT Business Edge sat down with Forrester Research executive Bruce Temkin to discuss this position. Whether the title is CXO, CCO (Chief Customer Officer) or SVP (Senior Vice President) and whether he/she reports to the CEO or CIO, the position has been developed to better align information technology strategy with business strategic initiatives. I have been involved in one customer-facing IT business solution project after another where different business sponsors were involved that illustrated to me that a more focused enterprise-wide customer experience view would have produced greater value to the business.

Over the next few years we will see this trend grow across America. Larger enterprises will quickly adapt to this new focus, having the resources to do so. Small to medium-sized businesses (SMBs) will come along slower, but will eventually wish to reap the benefits of this focus. This article from Forrester discusses these benefits and the responsibilities of the position in more detail.

With a more enterprise-wide focus on the customer experience driving enterprise application development and IT business solutions as well as customer service and other business areas, the organization should see a valued increase in customer relationships that can drive profitability.

Who should be responsible for Disaster Recovery Planning?

Friday, July 18, 2008 by Aaron Whittenberger

Many organizations consider Disaster Recovery Planning an Information Technology Strategy and place the responsibility for it in the hands of the CIO, who in turns holds IT Infrastructure Management accountable for Disaster Recovery Planning. I propose to you that you need much more than a Disaster Recovery Plan (DRP) to fully protect your business and ensure that you will stay in business following a major disaster. I further propose that responsibility for DRP is misplaced.

Many organizations use different terminology in this area, often interchangeably and incorrectly. A Business Contingency Plan is made up of three parts, Incident Response Plan (ISP), Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP). Also, businesses often put the responsibility for all these plans onto the IT department. Business Contingency involves the entire organization, not just IT; therefore the responsibility for Business Contingency planning falls to the CEO and everyone under him or her, not the CIO. Just as there are three different plans, with three different objectives, there should be three different teams responsible for these plans; with some overlap of personnel.

The ISP handles all small time-frame technical issues that may, or may not, involve the entire company. These would be IT infrastructure failures, hacker attacks or viruses. These would be handled by the IT infrastructure team and fall under the direction of the CIO.

The BCP is concerned with keeping the business running during a disaster, natural or man-made. This involves relocating the business if necessary for temporary operation for as long as necessary in response to normal facilities being uninhabitable. The BCP can also be initiated if an IT infrastructure failure goes beyond a pre-determined time threshold. As this deals with business operations, this falls under the direction of someone with COO authority.

The DRP is often initiated with, or shortly after, the BCP and deals with getting the business back to normal operations. This is getting the normal facility back into operational status, or if completely loss, obtaining new facilities for the company. As this is largely a financial matter, this falls under the direction of someone with CFO authority.

This does not mean that IT will not be involved with the BCP or DRP. On the contrary, each plan needs a cross-business team to develop, maintain and test the plan. IT and business unit members will serve on each team. Testing of the plans, at times, should involve the entire organization. Just as you run fire and tornado drills to protect your people, business contingency plans should be tested to protect the resiliency of the business.

Some members of these three teams will make up the Business Contingency Team, which is directed by the CEO. Part of business contingency planning is mitigating the risk of a disaster hitting the company, or mitigating the effect of the disaster on the company. Each of these plans should identify types of, evaluate the probability of and formulate risk mitigation for disasters.

So to ensure that your organization is ready to respond in the event of a disaster and to ensure that you will stay in business following even the most severe of disasters, you need a fully integrated Business Contingency Plan, not just a Disaster Recovery Plan. This plan should be part of the company culture; everyone should know of them and know their responsibility when one of the plans is activated. Business Contingency Planning is not an IT Solution; it is a business preparedness solution.

Is the High Price of Gas Prompting Growth in Telecommuting?

Monday, July 7, 2008 by Aaron Whittenberger

With gas prices over $4 per gallon across America now, one would think that telecommuting would be on a tremendous upswing. The fact of the matter is that telecommuting is still growing in America as it has over the past 5 year, but it is showing only a slightly higher growth these past few months than in the past 5 years. So the high price of gas has not sparked a spike in the telecommuting area. However, it remains a strong Information Technology Strategy for many organizations. “If a company was dead set against this a year ago, then the fact that employees now are paying $4 a gallon isn’t really enough to make them start doing telecommuting, unless they are at a point where they are losing employees for this reason. In that case, pain is a tremendous motivator to get employers to rethink this,” says Gil Gordon of Gordon Associates, a telecommuting and virtual office consultancy.

“Over the years there has been so much growth in telecommuting and mobile work in general, and so many people use laptops and cells, that it isn’t as huge a jump for more people to begin doing it, whether the [immediate] reason is gas prices, hurricanes or a bridge being out. Certainly, it is something that smart employers are looking at to ease some employees’ pain. But it is more a case of companies expanding what they already are doing rather than starting from scratch” adds Gordon.

Telecommuting is increasingly becoming an option for IT staffing, just as it is for their business peers. A new survey from Robert Half Technology shows that 21% of 1,400 CIOs in companies with more than 100 employees say there is more telecommuting among IT staff than there was five years ago.

"That's pretty significant," says John Estes, VP at the Information Technology staffing firm. "People resisted it for so long - there were issues of control, productivity, security and all that. But more companies are trying to think of creative ways to attract and retain staff." Providing workers the option to work at home one day a week or more is one way to do that, because it helps workers in an employee-driven market enjoy a better work-life balance, he says.

So if you wish to convince your boss that telecommuting is a good IT strategy for your work environment, remember the company wants to know the benefits telecommuting can provide the company, not the employee. Those will be the best selling points on which you need to base your proposal:

Cost savings – office overhead is the main cost savings. Less office space needed, means future office expansions can be delayed and fewer lights will be used.
Increased productivity – increases of 10% - 40% have been reported from telecommuting workers and their managers. Less commuting time, less office distractions and favorable response from workers for the company’s signal of trust are reasons cited for this productivity increase.
Improved motivation – again from the company’s signal of trust and the adoption of a flexible work environment.
Skills retention – employees less likely to leave for jobs that do not offer telecommuting when they already have this benefit. Also workers may stay with the company when the family moves because another family member changes jobs and does not have telecommuting available.
Organizational flexibility – in the event of restructuring or reorganization workers can continue to work with less disruption into their personal lives. Workers work in disperse teams that can be assembled and reassembled as the organizational needs change. Working time can be adjusted to match peaks and valleys in workload.
Enhanced customer service – customer service can be extended beyond normal work day hours or the work week without the cost of overtime or the staff to work or travel at unsocial hours.
Green is the word – As Michael noted as one of IT Management Challenges for ’08, less cars on the road, less pollution, less energy to light offices, possibly less server capacity needed means less climate control facilities required.

Telecommuting provides the employee benefits of cost and time savings of travel, less disruption of family life, better work-family life balance, greater employer loyalty, participation in local community and flexible hours.

Telecommuting or telework may not be an effective IT strategy for every organization. Some jobs are better suited than others to be carried out at home, as well. Sorry, network administrators and network engineers. IT staffers who might have better luck getting the boss to let them work at home include those with titles such as documentation specialist, programmers, and in some cases help and support desk personnel. If your organization has never looked at this IT strategy, it is worth a look.

It Depends

Monday, July 7, 2008 by Jeff Welsh

It depends, two of the most common words used in Information Technology Consulting. I will be spelling out Information Technology in this post because in this case it does not mean Information Technology. It means whatever context that is being used. Confused yet?

In consulting it depends on the specific situation as to whether a certain information technology strategy will work or not. It depends on the customer whether certain things are allowed or not. It depends on the information technology infrastructure. Sometimes people get frustrated when they can’t get a straight answer to what appears to be a simple question. I sometimes get criticized because it sounds like I don't know the answer or don't come across as being a very good information technology consultant.

Here is an example: Would Microsoft Exchange be a good email server to use? The short answer might be yes, but without asking a few more qualifying questions, that might not be the best answer. So what's my answer yes or no? It depends; tell me a little bit more about your information technology infrastructure. If the person says that they are running a Novell network, perhaps GroupWise might be a better choice. If they tell me that they are running an iSeries or a Linux network, perhaps IBM Domino might be better choice.

It is my opinion that a good information technology consulting firm will always say it depends because they want to ask a lot more questions before giving advice.

BA; The Communicator--Standardizing Business Process Modeling

Wednesday, July 2, 2008 by Aaron Whittenberger

In my mind, the greatest value a business can get from a Business Analyst (BA) during a SDLC project is as a Communicator. Time and time again I hear comments like:

IT does not know how to speak to business, or vise versa
Project failure is blamed on poor business requirements documentation
Project failure is blamed on poor solution design that did not meet the business requirements

In each of these situations, the real failure is communication. Whether it is knowing the lingo, requirements documentation or solution design; the trick is to put the message in a format that your audience can understand. This is where the BA can be most effective.

Very often the communication during many stages of the project is done through Business Process Diagrams (BPD), or business modeling. Unfortunately, there are scores of business process modeling languages, tools and methodologies. The adoption of Business Process Modeling Notation (BPMN) standard notation will help unify the expression of basic business process concepts as well as advanced modeling concepts.

The Business Process Modeling Notation, version 2.0 due out this year, is a standardized graphical notation for drawing business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is now being maintained by the Object Management Group (OMG) since the two organizations merged in 2005. It contains very specific graphical representation for each element of a business diagram including events, activities, gateways, connecting objects, data flow, data objects, groups and annotation.

The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers and technical consultants responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.

Business process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover this wide range of usage and allows modeling of end-to-end business processes to allow the viewer of the Diagram to be able to easily differentiate between sections of a BPMN Diagram. The following are the types of business processes that can be modeled with BPMN:

High-level business process activities (not functional breakdown)
Detailed business process
As-is or old business process
To-be or new business process
Detailed business process with interactions to one or more external entities (or “Black Box” processes)
Two or more detailed business processes interacting
Detailed business process relationship to Public Process
Detailed business process relationship to Global Process
Two or more Public Processes
Public Process relationship to Global Process
Global Process only (e.g., ebXML BPSS or RosettaNet)
Two or more detailed business processes interacting through their Public Processes
Two or more detailed business processes interacting through a Global Process
Two or more detailed business processes interacting through their Public Processes and a Global Process

BPMN is designed to allow all the above types of Diagrams. However, it should be cautioned that if too many types of sub-models are combined, such as three or more business processes with data flow between each of them, then the Diagram may become too hard for someone to understand. Thus, we recommend that the modeler pick a focused purpose for the BPD, such as one business process, or one global process.

As you can see the adoption of the BPMN can significantly reduce the errors caused by miscommunication during a project. This is one way that Information Technology strategy can align itself to better support the business strategic goals and objectives and produce better IT business solutions. All organizations would be well advised to adopt the BPMN, and the BA should be the driving force behind its adoption.

Communication, the consultant’s competitive advantage

Thursday, June 26, 2008 by Matt Warman

Any manager will tell you that effective communication is the key to any successful project. To have a person who can communicate to both business and information technology staff is a big asset. Consultants can fill this role because of skills required of them. Consultants need to regularly meet with the senior management. Consultants have learned to discuss the projects in a less technical manner, yet let management know the status and direction of a project. Consultants also work with application software developers, and enterprise architects, which means creating design and architectural
documents, and technical specifications.

Many of my assignments put me in a mentoring role. I am not only designing and developing for a project, but passing my knowledge and teaching best practices to junior application development staff. I am writing documentation for the maintenance and upgrade of the project.

I am asked by my boss to give presentations for clients and peers, or to train internal staff. I need presentation creation and delivery communication skills to perform these duties. Consultants are often invited to functions outside of work, to network with peers and executives for a variety of reasons.

As you can see, consultants routinely interact all kinds of people, from the most junior developer, to the CEO of the company. Consultants possess effective
communication skills to handle such diverse interactions. If you are having communication issues on your project, then hiring a consultant is a good information technology strategy..

Does Experience Matter?

Monday, June 23, 2008 by Matt Warman

The trend in information technology strategy these days is to employ offshore software application development, and to have a staff member manage the offshore team. This replaced the practice of hiring a junior software developer. The process typically goes like this: The Business analyst and project manager define the scope and requirements, and gives them to an application development manager. The development manager gives the requirements to the application develop team and handles any questions. The application development team codes from the requirements. This process is usually cheaper, because you don’t need a senior developer in the mix.
Surprisingly this process doesn’t work as well as anticipated. The code often needs to be rewritten, because it doesn’t fit the business objective. Why is this? Despite the view of some in management, application software developers not only know about information technology, they also know about business. Software developers usually have a relationship with the business units and testers they are supporting. Application software developers gleam business knowledge by supporting their customers. Over the course of 15 years or more, these application software developers have taken on more important projects, and have to support business management objectives as well. Sure experienced application software developers costs a lot, but their benefits are enormous. Senior developers have made the mistakes, and have learned from them. Experienced developers can easily stop design mistakes early, saving money. They mentor junior developers, helping them learn the business and IT quicker. They help with the processes and procedures to make business application projects work better and cheaper. Experienced personnel can bridge the knowledge gap between legacy and modern applications.

Does experience matter? Did you become the boss on the first day of your job?

Enterprise Application Trends

Monday, June 16, 2008 by Michael Kiffmeyer

Vendor consolidation has changed the enterprise application landscape. This presents additional challenges for CIO’s everywhere but there are some definite steps that an organization can undertake to make sure they are meeting the ever-changing work environment.

"Globalization, rapid market change, a changing workforce and regulations have turned the desire for more agile and usable applications into a business imperative," says Sharyn Leaver, research director of business process and applications at Forrester Research. "The result: process and applications professionals are on the hook to deliver more agile and usable applications."

One of the first approaches to consider is who you choose to work with for your enterprise application development work. Does your service provider work in a silo and merely do what they are asked or do they develop in an iterative environment that enables your team to become part of the process that allows for change as needed letting you continually meet the demands of your market place? Do they offer your organization real thought leadership? Can they assist you in proving the “real business benefits” from enterprise systems while also taking advantage of advances in new technologies that can allow my organization to plan more strategically instead of reactively?

We have witnessed first hand the rapid consolidation of companies purchasing other companies leaving organizations a few big players like SAP and Oracle to choose from. To ensure that previous IT investments are protected and that applications meet the business goals and objectives of your overall strategies. Working with and experienced consultant that are in-sync with the organizations information technology strategy can help prevent the on-going problems of systems not accessing the right data at the right time.

Through the rapid progression of previously mentioned application consolidation many companies must realize it is important that your organization meets its’ needs, not the wants of the vendors. Technology is merely a tool to enhance or processes, methodologies and workflow for the purpose of increasing productivity and final results. Working with the right information technology consulting firm is crucial to ensure this happens it a smooth efficient manner. Making sure that whatever application your organization chooses can be changed as needed and continually meets the need of you people, clients and the market place.

Disaster Recovery: Walk the Walk

Friday, June 13, 2008 by Aaron Whittenberger

Yesterday I wrote about writing a Disaster Recovery (DR)/Business Continuity (BC) Plan, whichever you wish to call it; and the things that should be covered therein. So we learned to “Talk the talk”, now let’s “Walk the walk”. That is done in two words: TEST IT. As I stated yesterday, your plan is absolutely worthless unless you know it works; and the way you prove that it works is to test it.

First of all, let me take some of the myths out of DR testing:

Testing requires shutdown of production systems
Testing is a linear process and hangs if expected results are not achieved
Testing takes resources away from real work
Testing reveals mistakes in planning, compromises management backing and costs you your reputation and possibly your job!

Testing can be done in parallel with production systems running. If your storage strategy is redundant cold servers, then fire those bad boys up and test how fast you can load the data and get them available to support the business. If your strategy was replacement, then get the replacement servers in, maybe you can rent them to reduce the cost, and test whether you have all the software, including operating system; and data available to make them production ready.

I support objective testing. Take a subset of objectives from the DR plan and test only those objectives. Make them non-interdependent objectives so if one test fails, the following tests can still be conducted. Tests can be scheduled on a regular basis throughout the year on different sets of objectives, with all objectives tested by year end.

Disaster recovery testing is real work. It is part of the job of the IT department to ensure they are ready to respond to any disaster from a virus to a natural disaster that levels the building. How many times have you practiced fire drills and tornado drills at work? That is a company showing social responsibility, and DR testing is no different.

Testing should not be the end of the process and a test that did not achieve expected results should not be viewed as a failure. This is an opportunity to make the DR/BC Plan better. There are no failures, just opportunities for improvement. Remember that the objective of testing is to ensure the continuity of business, safety of your people and restoration of your data in the face of a disaster. A failed test shows you what part of the plan did not work, so you can improve that part to ensure success in an actual crisis.

So how do you execute an objectives disaster recovery test? It is a process:

Dissemination of the scenario
Declare the disaster
Implement mock recovery activities
Monitor the progress
Document the work performed, timing and problems encountered
Orderly completion of the test and documentation of the results
Immediate analysis of the results

Disseminate the scenario. No surprise testing, tell the participants of the test the scenario of the test. What objectives are you testing and how are you going to conduct the test.

Declare the disaster. Inform the whole organization that disaster recovery testing is being performed. At time to start the test, declare the disaster has occurred and kick off the testing procedures.

Implement mock recovery activities. Any activities that cannot actually be performed can be mocked. If you are not bringing in actual replacement servers, you can actually send someone to retrieve off-site data backups. This will verify they know where to go to retrieve them and that they have access to them. There is nothing worse than to have one or two names on an access list to your off-site storage and those one or two individuals not be available.

Monitor and document. Monitor activities, verify everyone knows their duties and performs them in proper order, if needed. Do not allow auditors to interfere or interact in the process. Do not allow by-standers. Hand them a clipboard and have them document activities. Document the work that is performed, timing of such and the results of the work, including any issues that resulted.

Orderly completion of the test and immediate analysis. Call an end to the test. Gather the participants in a conference room and immediately document and analyze the results. Do not allow people to rethink steps, or think what they should have done. Do not allow for lapse of memory before documenting the results. Analyze what actually happened during the test. Document the results of the test for management.

Now go back to the Disaster Recovery Plan and see if it needs revised due to the results of the test. Then begin preparation of your next test. Remember to test only a subset of objectives. Test regularly and on a schedule, having all objectives tested annually. Testing should occur after any significant change in business or infrastructure; and make allowances for re-testing in your schedule.

Keep in mind that an effective Disaster Recovery Plan is not just an IT solution, it is an IT business solution to an issue that every business faces. Only 50% of organizations even have a Disaster Recovery/Business Continuity Plan. Of those, fewer that 50% do any kind of testing of the plan, which in effect is like having no plan at all. Today, with growing organizational dependence on information technology strategy, systems and TI solutions; the potentially devastating impact of man-made and natural disasters on business processes and finances, and employee well being is now greater than ever. It is estimated that up to 80 percent of companies without a well-conceived and tested business continuity plan go out of business within two years of a major disaster. Make sure this doesn’t happen to your business.

What we have here is an IT failure.

Thursday, June 5, 2008 by Jeff Welsh

I really liked Struther Martin in the movie ”Cool Hand Luke”, especially the famous line, “ What we have here is a failure to communicate”.

I recently attended a class at MIT in Cambridge, Massachusetts. The class was about information technology strategy, and IT organization. One of the questions that was addressed during this class was: Why do so many IT projects fail? Now there are a lot of reasons why a project may fail and to address of the reasons now might be a little cumbersome.

One of the statements that really stuck me was that an IT failure was really a business failure. Too many times I’ve seen business units and IT in a finger-pointing match. One of the suggestions that came out of this class was rather than having a separate business strategy and IT strategy, shouldn’t the IT strategy be a component of the overall business strategy. Now that sounds simple enough, but it's not actually implemented more often than not.

One way to start accomplishing this would be to tie business units and IT units together. That would mean that the career aspirations of both the business management and the IT management would be tied to delivering functional projects. Maybe then more companies would embrace the statement that an IT failure is really a business failure.

What are your thoughts?