Once you have set your goal for a project and have visualized the results, you need to start looking at your project team. In most small businesses, there are not a lot of people available to work on such a project. That's why most small organizations take the lead of the software supplier, and let them run wth most of the project.
In larger organizations, where there are people who can dedicate themselves to the project, they tend to be technical people and the total focus is on the implementation of the software.
This is mistake #2.
The software will not deliver the results that you need! Your people will! They will only do that if they are aware of your goals and your vision, are educated in the tools necessary to deliver your vision and work together to make it happen.
Your project team must consist of the people who will be doing the job after implementation, the technical resources that will implement the software, the people who will provide the education and training. Most of these people will not be dedicated to the project. They will do activities that are required, but they must all understand the goals, the vision and their roles before during and after.
The big mistake that many organizations make is to not involve the people who are currently doing the job, because they are too busy. They are the people who understand what is being done, must understand what has to be done after implementation, and must be involved during the project.
The four key elements of this phase are: Awareness, education, involvement and teamwork.
Friday, March 20, 2009
Thursday, March 19, 2009
Four steps to success of software projects - Step 1
When you consider buying, installing or upgrading business software, the starting point is asking the question - why?
It may be that you want to increase sales, increase productivity, decrease costs, improve cash flow, etc. The reason doesn't matter. Most often and organization will jump from this broad goal right to looking for software products, or talking to friends or colleagues about what they used. This is a big mistake! The goal is too loosely defined. Everybody in the organization and your suppliers will have a different view of how to achieve this goal. How you achieve this goal will depend on what you mean by it. And this is different from person to person, company to company.
You need to be able to visualize what this goal means. For example, if you are considering Customer Relationship Management (CRM) software, is it your intent to become more intimate with your customers, understand their needs and wants even when you can't satisfy them, understand every interaction? Or do you just want a contact manager and the ability to track sales in process?
This step is the most important!
Once you have visualized the solution, you need to identify how you will maintain the energy to deliver the results. Most software projects are more of a marathon than a sprint. As much of the activity is technical and of no interest to the business, most business people get tired and ignore the project waiting for something that they can get involved in, in spurts. They are busy running the company and can't focus on the project the way that technical staff do.
During this step, you need to identify deliverables that are to be performed by the business to move it forward. You must identify activities that can be done in spurts that help to move the project along and maintain focus.
As leaders, you must also maintain this focus by looking for results, improvements in te short term and not be satisfied with waiting to the end.
These four elements: Goal, vision, focus and leadership will be critical to the ongoing success.
It may be that you want to increase sales, increase productivity, decrease costs, improve cash flow, etc. The reason doesn't matter. Most often and organization will jump from this broad goal right to looking for software products, or talking to friends or colleagues about what they used. This is a big mistake! The goal is too loosely defined. Everybody in the organization and your suppliers will have a different view of how to achieve this goal. How you achieve this goal will depend on what you mean by it. And this is different from person to person, company to company.
You need to be able to visualize what this goal means. For example, if you are considering Customer Relationship Management (CRM) software, is it your intent to become more intimate with your customers, understand their needs and wants even when you can't satisfy them, understand every interaction? Or do you just want a contact manager and the ability to track sales in process?
This step is the most important!
Once you have visualized the solution, you need to identify how you will maintain the energy to deliver the results. Most software projects are more of a marathon than a sprint. As much of the activity is technical and of no interest to the business, most business people get tired and ignore the project waiting for something that they can get involved in, in spurts. They are busy running the company and can't focus on the project the way that technical staff do.
During this step, you need to identify deliverables that are to be performed by the business to move it forward. You must identify activities that can be done in spurts that help to move the project along and maintain focus.
As leaders, you must also maintain this focus by looking for results, improvements in te short term and not be satisfied with waiting to the end.
These four elements: Goal, vision, focus and leadership will be critical to the ongoing success.
Wednesday, March 18, 2009
Four steps to success of software projects
Many business owners are frustrated with the performance of Information Technology in their business. To some, it is the reliability of the hardware and software, to others, it is the language of IT that gets them. They are trying to run their business and unless they are technicaly proficient, they get frustrated.
The real issue, though, is their sense of value and lack of control. They don't feel that they are getting as good a return on their investments and are frustrated that they can't seem to do anything about it.
This doesn't have to be the case. As a business owner, you don't have to be technically skilled, like you don't have to be a mechanic to drive a car.
The problem is that all of the focus is on the car. If you had to know how to repair a car before you could drive, most of us wouldn't drive. If most of us knew how to repair a car before we drove, car manufacturers wouldn't have to put any effort into preventing them from failing.
Unfortunately, computers haven't reached that place yet. Most computer technicians believe that everybody should be knowledgeable about computers, so they don't consider speaking business language.
In order to fix this problem, we have to change our attitudes. As business owners, we need to insist that software developers and companies focus on the business issues and not just on implementation of the software. If we ensure that they do this, we will increase the value that we receive, decrease the frustration and improve our business performance.
Where do we start?
My approach is to change the sequence. Often a business project that will require software, moves straight into the project development phase and all future focus is on the implementation of the software. This is the problem period and is the source of all future problems.
My approach goes through four steps:
1. Purpose
2. People
3. Process
4. Technology
Yes, technology is the last step. It may be the largest. It may be the longest. Many of the benefits can be received before the software is fully implemented. There are big benefits in the first three.
I will outline each of the steps and their benefits in future posts.
The real issue, though, is their sense of value and lack of control. They don't feel that they are getting as good a return on their investments and are frustrated that they can't seem to do anything about it.
This doesn't have to be the case. As a business owner, you don't have to be technically skilled, like you don't have to be a mechanic to drive a car.
The problem is that all of the focus is on the car. If you had to know how to repair a car before you could drive, most of us wouldn't drive. If most of us knew how to repair a car before we drove, car manufacturers wouldn't have to put any effort into preventing them from failing.
Unfortunately, computers haven't reached that place yet. Most computer technicians believe that everybody should be knowledgeable about computers, so they don't consider speaking business language.
In order to fix this problem, we have to change our attitudes. As business owners, we need to insist that software developers and companies focus on the business issues and not just on implementation of the software. If we ensure that they do this, we will increase the value that we receive, decrease the frustration and improve our business performance.
Where do we start?
My approach is to change the sequence. Often a business project that will require software, moves straight into the project development phase and all future focus is on the implementation of the software. This is the problem period and is the source of all future problems.
My approach goes through four steps:
1. Purpose
2. People
3. Process
4. Technology
Yes, technology is the last step. It may be the largest. It may be the longest. Many of the benefits can be received before the software is fully implemented. There are big benefits in the first three.
I will outline each of the steps and their benefits in future posts.
Sunday, March 8, 2009
Is Resistance to Change a problem for IT projects?
I read about a lot of project failures that are classified as failures due to resistance to change. I was recently speaking to a consultant who was talking about Customer Relationship Management (CRM) projects and the challenges that they face.
All change encounters resistance when there is no benefit shown. If there is no benefit to making a change, then why should I change? After all, I listen to WII-FM (What's In It For Me). All change is difficult. We have to want a change in order to go through the effort to make a change. Just look at people who have lost weight, quit smoking, etc. They had to really want to change. To people who run IT projects, resistance to change is common. However, most of them are deeply involved in the change, see the value or potential value and are comfortable with technology. They can't understand why people don't embrace this new solution.
Often people involved with a project don't see it as a change, or at least don't see the negative side of it. Any change requires a refocus, a relearning, a move from subconscious activity to conscious activity. This is very time consuming. Your productivity goes down. However, business volumes don't (except for a recession, when staff gets cut to compensate). This means you take more time to do your normal job, and therefore will encounter more stress. Who wants that?
Much has been written about organizational change and cultural change and the efforts to get everybody on board. All of these changes are the same and require the same kinds of effort. If people don't understand the goal, don't understand how they can contribute to the goal, they won't support the pain that they have to go through to get there.
When a project fails due to resistance to change, it has still failed. It has failed because of a lack of recognition that people are listening to WII-FM. What's playing on your station?
All change encounters resistance when there is no benefit shown. If there is no benefit to making a change, then why should I change? After all, I listen to WII-FM (What's In It For Me). All change is difficult. We have to want a change in order to go through the effort to make a change. Just look at people who have lost weight, quit smoking, etc. They had to really want to change. To people who run IT projects, resistance to change is common. However, most of them are deeply involved in the change, see the value or potential value and are comfortable with technology. They can't understand why people don't embrace this new solution.
Often people involved with a project don't see it as a change, or at least don't see the negative side of it. Any change requires a refocus, a relearning, a move from subconscious activity to conscious activity. This is very time consuming. Your productivity goes down. However, business volumes don't (except for a recession, when staff gets cut to compensate). This means you take more time to do your normal job, and therefore will encounter more stress. Who wants that?
Much has been written about organizational change and cultural change and the efforts to get everybody on board. All of these changes are the same and require the same kinds of effort. If people don't understand the goal, don't understand how they can contribute to the goal, they won't support the pain that they have to go through to get there.
When a project fails due to resistance to change, it has still failed. It has failed because of a lack of recognition that people are listening to WII-FM. What's playing on your station?
Wednesday, March 4, 2009
The last mile of software development
I read a paper recently that talked about the last mile of software development.
The software development process was described with the following components:
Describing it as the last mile may be part of the problem and the fact that many software projects fail to deliver on their promises. The same is often true when a business buys a software product. The only time that value is created is after installation of the software, when improvements in the business are actually received. And even then, it is not the last mile. Your initial implementation will not be as valuable as when your people become comfortable and productive with it.
So implementation is not the last mile. This is where you need to focus.
If your supplier or your staff view the implementation as the last mile, maybe you need to change one or both.
The software development process was described with the following components:
- Business requirements are identified.
- The software is developed (seen as most important by developers)
- The software is tested
- The software is implemented.
This last stage was called the last mile of software development.
If we look at it from the business perspective, no value is created until the last mile. Until the software is implemented, the business gets no value (except for software development companies).Describing it as the last mile may be part of the problem and the fact that many software projects fail to deliver on their promises. The same is often true when a business buys a software product. The only time that value is created is after installation of the software, when improvements in the business are actually received. And even then, it is not the last mile. Your initial implementation will not be as valuable as when your people become comfortable and productive with it.
So implementation is not the last mile. This is where you need to focus.
If your supplier or your staff view the implementation as the last mile, maybe you need to change one or both.
Tuesday, March 3, 2009
IT Value comes from speaking business language
I was at a seminar recently that was focused on helping new immigrants to integrate into our society. You may ask why this has anything to do with computers.
It is probably the major issue and the reason why many business people get frustrated with IT staff and suppliers. The issue is communication.
Despite the proliferation of computers in our society and in business, the reality is that maybe 20% of people are comfortable with computers. Many of those people are comfortable with the games, but not any more comfortable with business use. When I speak to small business owners, and many staff, they are often frustrated with computers. This is a result of computer speak and lack of focus on the business issue.
Most business owners know they have to use computers and want to, but when they speak to the technicians, all they get is computer talk. They are told all of the great things that computers can do for them, but in terms of the software or hardware, not in terms of their business.
Getting back to the seminar, one of the things that was stated was, "In order to make new immigrants productive and effective in our society, you have to make connections with them, speak to them in their language". This doesn't mean that they don't have to adapt. However, the more stressful that you make the interaction, the slower they will be to adapt to their new environment.
This is also true for people who are uncomfortable with technology. If you force them to speak the new language, and they don't see how it helps them, they grow frustrated and "tune out". The only reason why technicians don't speak their language is often that they don't know the language of business, even though they profess to know it by their selling approach. The sales pitch talks about solving business problems. However, the implementation approach seldom does.
This is the primary reason why IT projects fail. The steps go as follows:
It is probably the major issue and the reason why many business people get frustrated with IT staff and suppliers. The issue is communication.
Despite the proliferation of computers in our society and in business, the reality is that maybe 20% of people are comfortable with computers. Many of those people are comfortable with the games, but not any more comfortable with business use. When I speak to small business owners, and many staff, they are often frustrated with computers. This is a result of computer speak and lack of focus on the business issue.
Most business owners know they have to use computers and want to, but when they speak to the technicians, all they get is computer talk. They are told all of the great things that computers can do for them, but in terms of the software or hardware, not in terms of their business.
Getting back to the seminar, one of the things that was stated was, "In order to make new immigrants productive and effective in our society, you have to make connections with them, speak to them in their language". This doesn't mean that they don't have to adapt. However, the more stressful that you make the interaction, the slower they will be to adapt to their new environment.
This is also true for people who are uncomfortable with technology. If you force them to speak the new language, and they don't see how it helps them, they grow frustrated and "tune out". The only reason why technicians don't speak their language is often that they don't know the language of business, even though they profess to know it by their selling approach. The sales pitch talks about solving business problems. However, the implementation approach seldom does.
This is the primary reason why IT projects fail. The steps go as follows:
- Define the business goal
- Develop the technical implementation plan.
- Train staff of the functions of the software
- Implement the software
- Have people figure out how to use the software to do their business functions
- Find new ways to address the functions that can't be done by the new software.
If we change our approach, we get:
- Define the business goal
- Describe the business process that will help us achieve the business goal.
- Define how the software will help improve the process to achieve the business goal.
- Define the process and technical implementation plan.
- Train people how to use the software to implement the process improvements
- Implement the software
- Support people in their learning how to improve the process using the software.
In this case, all of the focus is on improving the process to meet the goal. The software is simply the tool that helps, and there should be no confusion as to why you need to learn the software. You also don't waste time on learning parts of the software that don't help improve the process.
Monday, March 2, 2009
Is your project a technical project or a change project?
Many projects fail to achieve the business results that were expected when the business started to plan for them. The basic reason is that the projects are seen as technical projects, that is, delivering a new piece of software that may be necessary to automate a business function.
While that software may be required to deliver the function, it is seldom sufficient. The software assumes that certain things are in place (I know that software can't assume, but the programmers do). In many cases, the software creates the opportunity to build a new business process. That business process would not be possible without the software, but it seldom addresses all of the problems. The changed business process may require changes in roles and responsibilities, new interfaces between people and departments, totally different activities. If those new functions are planned for, then the process falls down. In many cases, new approaches are developed after the implementation. Although this works, it is seldom efficient.
If the process is designed when the software is developed, all changes can be planned for. In many cases changes to the process can be completed before the software is implemented, thereby gaining some of the benefits early.
Don't assume that a technology project is a technology project, to be left to technicians. Make it a complete change project and paln for all of the activities that the technical people probably won't think of.
While that software may be required to deliver the function, it is seldom sufficient. The software assumes that certain things are in place (I know that software can't assume, but the programmers do). In many cases, the software creates the opportunity to build a new business process. That business process would not be possible without the software, but it seldom addresses all of the problems. The changed business process may require changes in roles and responsibilities, new interfaces between people and departments, totally different activities. If those new functions are planned for, then the process falls down. In many cases, new approaches are developed after the implementation. Although this works, it is seldom efficient.
If the process is designed when the software is developed, all changes can be planned for. In many cases changes to the process can be completed before the software is implemented, thereby gaining some of the benefits early.
Don't assume that a technology project is a technology project, to be left to technicians. Make it a complete change project and paln for all of the activities that the technical people probably won't think of.
Subscribe to:
Posts (Atom)
Posts
