Lessons Learned
Home Marketing Tools Project Tools Basic Information Reengineering Trends Book Reviews Technical Support Info. Web Site Bibliography Lessons Learned

Lessons Learned from a Real Reengineering Project

For those of you who do not know me my name is Kelly and I spent a little over a year and half working on a reengineering project for a Fortune 500 financial company. This web site contains information that I think would be helpful for a newly formed team to look at during their reengineering experience. My reengineering experience to say the least was different from what you will read about in the Reengineering Revolution and much of the other material presented in this web site. It had both its positive and negative points like any experience but if I had to do over again there are many things that I would do differently. Below is the summation of things that I would recommend to others based on my own personal experience on a reengineering team.

Trust your own instincts. Consultants are great for getting things started and presenting ideas but if they are trying to drag out your project say so and move on.
Always take notes during meetings. Organize them by topic or category rather than by date because when a question comes up about a certain topic you can usually never remember the exact date of the conversation but you know the topic.
Do put dates next to the entries within the topic pages so that ideas do not get out of sequence.
If a decision is made always record the rationale for that decision and why it was chosen over the alternatives so if you have to explain it in the future its all there.
So much time is wasted trying to remember information at a later date and credibility is lost when you do not have the rational easily available to back-up your decisions.
I think that my project would have been a whole lot more efficient if we had used the web based Intranet documentation programs that are available now.
Break large projects down into manageable chunks. My project started to grow out of control and it became so large that in the end only a tenth of what the team started actually came to be. Many of the team members ended up feeling like failures because we did not deliver what we intended.
Have a time limit for making small decisions as well as a team leader who will make the final decision if the team can not come to consensus. In my team there was no leader and everyone in the group had to agree to every decision before moving on to the next task. In the end so much time was wasted on decision making that was never even used because design changes made some decisions obsolete.
Always try to have a team that is comprised of cross functional members (different departments as well as levels of management), this aids in the perspective and type of information available the group. Make sure that there is a policy for replacing team members who leave. Sometimes it’s hard because of staffing concerns to get replacement people from certain areas of the company.
Ensure the buy in of top management as well as the rest of the company. If you do not have support your project will go nowhere. This is a very difficult task t accomplish. Communicate frequently to the general employee base and invite non-team member to participate for day in team meetings so that they can help spread the word about the team’s work.
Make sure that you have a deliverable that people can see implemented within a year at the latest. Otherwise, the perception of employees can turn on you quickly.
Have a critical path map for your project. If anything on the critical path starts running into problem raise the red flag immediately and get anyone who can possible help you to join in, don’t be afraid to ask for more staff during a crunch period.
Do not keep secrets in order to save face for the reengineering team. The information almost always comes out in the end and poor decisions may have been made based on faulty information in the mean time.
Always get information in writing. Need there be more said CYA in all cases even when dealing with other departments within your company.
Always get deliverables especially IT related ones spelled out and in writing with dates. Make each vendor or department accountable for meeting their tasks. The more information out there the more "pressure" there will be not to let this particular project date slide.
Always have a back-up plan. The unexpected can and usually does happen with large projects and it’s always good to be prepared. We lost all of our computer training rooms just prior to our implementation date but we were prepared with flexible training materials and were still able to conduct training.
Having a team mentor or other highly respected person promoting your project will definitely increase its chances of survival. With budget cuts and downsizing going on in many companies you must look out for your project’s longevity.
Use outside research tools. The team I was on only utilized consultants and internal company resources, which was limiting in hindsight. Some of the links provided in this web site could have provided quick answers and alternate solutions to our problems but we didn’t even know that such information was out there.
Don’t be bullied by consultants they do not work at your company and do not always know best. Use their information as a guideline but not the law. Our consultants stayed so long and charged so much they ended up almost bankrupting the project in the end. We felt that we did not know anything about reengineering so we had to go along with what they said.
Always start with a foundation of information for reengineering team members. Remember that if new team members are brought into the team at a later date that they need to be educated on reengineering as well as brought up to speed on the project specifics.
Do not underestimate the resistance to change that you will encounter at your company come implementation time. Be prepared to answer tough questions and provide positive benefits that the new process will bring to employees and customers.
If you can borrow, buy, or imitate (if legal) do so instead of creating a whole new technology yourself. The creation, implementation, and support will be costly as well as lengthy in many cases. There isn’t any history with a new product so it’s up to you to work out all the bugs.
Know your budget for the project including the team’s allotment. Our team was never given this information, we were just told to create the best product that we can within reason. Half way through the year we found out that we had used up all of our allotted team lunch money, overtime, and miscellaneous expenses and there was nothing left for raises the next year (not a nice surprise).
Do not get so caught up in the details of your project that your forget to take a look around at the current environment of your company and industry to see what is changing and what may affect your project plans.

I learned many things while working on this independent study for Loyola College. One of which is that every reengineering project is different but many aspects of planning and team dynamic problems are universal. I wish that our team had used outside resources like the kind provided in this web site because I think that we were very narrow minded as far as the way we perceived what the reengineering "rules" were according to the consultants. Since I was brought into the project after it had already begun, I did not receive any reengineering specific education until I had been on the project team for almost a year. There is so much information out on the Internet that I could have taught myself if I had been pointed in the right direction. I also found that now since leaving the reengineering team that I am constantly using the skills that I acquired in many aspects of my current position as a Business Analyst. I am always thinking ahead for what is the critical path and what process are behind and head of on any component that I am working. These critical thinking skills are highly prized and I feel that they will serve me well in my career.

Since reengineering is about thinking what makes the most sense and is value added. I decided to put this information into Internet format rather than hard copy paper since much of the information is comprised of web addresses. This format would save viewers the hassle of having to key in all of the URL web addresses. By putting all of this information into a web site I also learned a new skill, a crash course in HTML and FrontPage 98. I really liked working in HTML even though it was hard to picture what the site was going to look like when writing the script.

I hope that you find this site of some practical use in your reengineering endeavors.