Despite the obvious benefit to designing project plans to be “business driven design” with regard to “off the shelf” software implementations, there is little or no progress in big consulting firm methodologies. Still status quo
Clients still rely on new buzz words and staff augmentation without regard to their own internal knowledge development. They buy a car and let someone else drive it.
What is wrong with corporate America? If you can’t implement software successfully then what do you actually do in IT? Are you just an extension of HR or Purchasing?
Business driven design methodologies work in an environment of companies where business process owners actually know what their business is, how their business operations work, and why they do business a certain way. But that can be a problem as well. The most enthusiastic business people are typically left out of the implementations because they are busy doing something else. Tending an off the shelf software implementation on a part time basis is somewhat like letting a 10 year old watch your infant baby while you monitor the baby through a baby cam from a 100 miles away. This inhibits great projects because talent stays off the project. Ownership is either a rubber stamp or a hindrance due to client push back.
There is so much ineptitude in consulting these days that you must learn how to be in control of the staff augmentations that are occurring in your organizations. Consulting and staff augmentation should remain two different things! Treating these two things as the same thing inhibits business driven design basically by keeping talent out of your organization.
Headcounting expensive resources instead of monitoring their quality is a total lazy method. HR doesn’t know how to get the job done. They simply have some company like Teksystems lock every good resource out while they pull in the appropriately cheap foreign resources for the job. Because HR chooses not to actually put an effort into sourcing different organizations, your organization suffers from single source purchasing. Duh? Stop being in denial. Its happening and if you resent this blog then you are probably guilty of doing it. If you are an IT manager then you are quite capable of hiring good local resources and monitoring their abilities. You have every opportunity to send them home if they lied on their resume or lied in the interview. This belief that HR is right in narrowing your selection of resume sources inhibits business driven design because good resources cannot nor will not work for firms that take too much of the pie from the augmented workers. They tend to use their own “usual suspects” who will play the game according to Teksystems rules and payment terms.
You have to be cognizant about the acts of consulting giants trying to create a monopoly in your house. I had a client in or around Dayton Ohio who is clearly bullied and held for ransom by Infosys for no apparent reason except fear and proper payment. Ironically these companies staff hundreds of work permit holders (not green card holders) to staff a project where only 1 out of 10 actually has any experience doing what they are assigned. They fill cubicles, fill parking lots, and fill jobs that could be provided to out of work local workers. If they knew a skill and actually used it for the client I might understand a little. If you are an executive taking bribes from consulting firms then shame on you. If you are middle management doing that same thing then I hope you get caught. This practice inhibits business driven design because the client depends on other people to do their work.
I have never seen the job done better than with local resources that have vested self interest and pride in their own performance. Training takes less time and money than dishonesty does. I know that new developers can be made in months at really low costs versus fake developers claiming to be working on solutions for months.
The first presidential candidate that stands up for American business owners and stops the illegal misuse of US work permits by consulting firms will get my vote. Consultants hired by consulting firms in other countries then brought into the USA to be US based consultants should be an illegal practice and misuse of our work permits. If you are employed by a company as a regular employee and coming to US to work for the benefit of your company then that is a fair purpose of a US work permit. However, a consultant is a misuse if they are coming over to work and be based in the US working on multiple IT projects as they occur.
If you are implementing Oracle EBS modules and you don’t have a plan at the beginning of the implementation to ensure your appointed team members are well enabled to drive design of configuration and product accurate gap/business requirements then you are wrong wrong wrong.
Don’t misunderstand me. I believe in hiring and/or engaging people from all over the world to provide the best possible approach to any implementation. I just don’t believe in hiring overseas simply because they are overseas and perceived as lower cost equivalent quality resources. You shouldn’t either.
I have seen great globally present companies that actually use their employees first before they use staff augmentation from contractors or consulting firms. Business driven design for the implementation of “off the shelf” software packages like Oracle EBS means expanding your business people’s skill sets to include designing the configuration of the software application itself. Your “superusers” should be able to review, understand, and add content to a configuration document. Your superusers should be daily fully committed project team members who seek to drive design and be intimately involved in the configuration design that satisfy business requirements desired to be accomplished when the enterprise selected the package in the first place. If you don’t have time and commitment to this then why add a new system in the first place? Business driven design superusers try to get early adoption in their organization by implementing a solution that will be accepted by the users within the organization because they know what the enterprise needs and what they will need to meet the changes. Business driven doesn’t stop because the IT organization doesn’t know how to do something. It doesn’t get bullied by technical resources but it also is inclined to try to use the functionality as it is built by the software provider.
Business driven design can use agile or waterfall approaches in project methodologies because it is about relying on limited technical intervention in design of software usage. IT should be involved in infrastructure, solution development, installation and support of software but not trying to tell business how to run their business farther than the software can actually handle.
IT might make use of consultants and contractors to help or police business driven design. But, the main human element of the business driven design is actual business experts, (buyers, order takers, planners, inventory clears, warehouse managers, product managers, MDM managers, customer service reps., and other business operations personnel who understand their processes).
Business driven design for “off the shelf” software packages are optimal and shorter if they are done right. But the activity up front will foretell the success of the implementation. Early deliverables of a good business driven design are sound configurations, accurate RICE (reports, interfaces, conversion, and extensions), future organizational change requirements, faster adjustments to business environment changes, and more accurate progress reports within organization.
CRP (Conference Room Pilot) events prove success and progress. Have these events to allow the business project members to demonstrate the business requirements satisfied by the software application. POC (Proof of Concept) events allow the business driven project members to apply their knowledge of the software application to see how the software satisfies a business requirement. UAT (user acceptance test) events prove that the software and possible fulfilled RICE requirements have satisfied the business requirements. SIT (system integration testing) events show how well the software is integrated to other systems or other business areas or both. All of these events can be business driven if the project works on what the project members need in order to accomplish each event and business requirement. Plan by business requirements, not by IT requirements unless they are identical. And they should be identical because that means IT is working for the organization that it belongs to. Events help monitor the quality of the project. No one will report more candidly than internal business requirements experts as long as the organization allows this to occur.
You are not business driven if:
1. The business analyst has no experience in the enterprise
2. The business analyst has no desire to meet business requirements.
3. The business analyst has no motivation to provide design in the interest of the organization.
4. There is no upfront investment in software knowledge for the people responsible for the implementation. The consultant might be an expert in the software but the internal business analyst will know more about the organization’s business requirements. The software takes less time to know than the organization’s needs.
5. Throwing things over the wall. Part time business people have no motivation to give the project time and effort. Owning a piece of the project and having responsibility will provide more motivation. Consultants and contractors don’t need to do all the work.
6. Invest in senior software experts as advisors and mentors to your organization. Don’t think that you will get this from a big consulting firm. They don’t make money off of high priced experts unless they mark their price up substantially. Hire your own contractors and don’t try to bargain with them. Pay a good price for great software experts. My rate is high but so are my results. Pay less and you get what you deserve. I am laughing at your low cost mentality. duh!
7. Don’t bog people down with busy project reporting work. Give them time to analyze and design. Results are proven at events. If you want more reporting then schedule more events. But there is a cost to that kind of management. Business people need to focus and produce quality work.
8. Don’t stick them in the broom closet. If you treat them cheaply then expect that kind of morale and performance. Get and provide great resources. Not broken office furniture in dirty closets. Make it a healthy environment and expect better performance. Business people know by the way they are treated how important they are to the organization.
9. Executive sponsorship, support, and praise: If it isn’t important enough to provide feedback from executives then it probably doesn’t need to be done. Tell people continuously how strategically important the project is and how you affect the organization. Let them know how you are depending on them doing a great job. The truth shall set you free. You are the first business drivers!! You better drive the business or don’t expect anything but vague results and delays.
This is not all inclusive. These points are things I have observed at the low level of the implementations after 20 years of good and bad implementations. Use this along with some common sense to design project plans that really work.