Why aren’t big corporations jumping onto the web?

I work for the IT department of a large pharmaceutical and I’ve been trying to drag them into the 21st century. In my previous company, we used ICQ and Netmeeting for collaboration and we used Hotmail as our mail platform. Our infrastructure required no support, no servers and it was always updated and secure. I’ve explained to management how we save on costs if we moved off our ancient Lotus mail system to a hosted solution. I proposed using ICQ or Microsoft Netmeeting instead of our internal tools and using tools like vBulletin forums for collaboration. When I brought up MySpace for linking to our clients, I didn’t even get two sentences out before being shot down. Everyone else in the world seems to get that we’re moving to the web. Why can’t big corporations see the future?

Frustrated Technologist

I feel your pain. But I also understand the position of your management.

Small companies are more agile and accepting of risk because they can see it quickly and respond just as fast. If your mail host screws up, you can send out a quick memo and move your dozen employees to a new host overnight. If there’s a security breach on ICQ or Netmeeting, it’ll come up in the morning meeting and everyone will understand what they can and can’t do until it’s resolved. If someone has questions, they’ll walk over and ask “Ted the IT guy” for help. If there’s a lawsuit, the company lawyer can walk around and manually copy all of the relevant documents, emails, etc to a USB stick. If a service goes bankrupt overnight, moving to an alternate platform may simply mean that someone walks around and adds a new bookmark to everyone’s browser. If security is breached, the impact may be a few dozen customers or some proprietary information. It could be damaging to the company, but the scope is limited.

Large companies simply can’t accept these risks as easily. If a publicly hosted mail service screws up, they may have to inform 100,000 employees and migrate them to a new platform. That could be months worth of work and manpower. If there’s a security breach on a public messaging tool, it could be a month before everyone in the company even gets around to reading the memo. If there’s a lawsuit (and the bigger the company, the more of a target they become for frivolous litigation), you now have an issue of even identifying who and what is relevant to the case. By the time that you get around to identifying the information that you need, it’s probably been deleted. If the data is centralized and archived, it can be browsed on an as-needed basis. If security is breached, the data of hundreds of thousands of customers could be compromised. In the case of a pharmaceutical, trade secrets worth billions of dollars could be exposed or personal medical histories could become public knowledge. In addition to the loss of intellectual property, the company would also have a huge lawsuit from their clients and they’d be liable for substantial punitive damages.

Here’s an analogy that might help:
Imagine that a couple of college kids come knocking on your door and tell you that they’re offering a new banking service. You give them all of your money and they’ll pay you 10% interest and any time you need cash, you just call them and they’ll hand deliver it to you wherever you are. You check with their references and it all checks out as legitimate. They don’t have the overhead of insurance, offices, regulation or FDIC. They just keep the money in a bunch of labelled shoeboxes and take it out when you need it. From your perspective, they provide a great ROI and they provide much better service than your bank. Would you turn over your savings to them?

Increased size and complexity leads to an inevitable loss of agility. The advantage of centralized and internally hosted IT is that you have the control that you need to compensate for that lack of agility (somewhat). Unfortunately, that control is expensive and the need for it isn’t always obvious. It becomes a source of frustration to the people who are used to acting as individuals instead of part of a larger collective. It’s ironic that small companies lack the resources to fully leverage their agility and large corporations lack the agility to make the best use of their resources.

What it comes down to is that to an individual, information is something to be shared. To a corporation, it’s something to be hoarded and protected. That leads to the “command and control” mentality that we see in most large companies. It leads to processes and infrastructures that are focused on avoiding risk. It’s also what inevitably leads to the small, nimble startups taking market share away from the slow moving dinosaurs. The compromise is to educate your employees and let them run their areas like individual businesses. Lay out ground rules and strategies to keep everyone aligned, but start acting like a pack of coordinated lions/wolves/whatever instead of a single monolithic dinosaur. Let groups make intelligent decisions about whether or not they can accept the risk of using an external mail service or chat client. (but make sure that they *understand* the risk and their responsibilities) Let them choose the devices and software that they want to use as long as it conforms to the rules that matter. Sure you lose some of the savings that you got by commoditizing the decisions, but you also force the units to think on their own and manage their own risk.

As always, that’s just my two cents. I hope that it’s been worth at least that much to you 🙂

Who is more important – the partner who brings in the customers and manages the clients or the partner who does the back end operations?

I understand that they both are equally important to the success of a business but when it comes to sharing profit or deciding on a collaboration ratio – who should get more, by how much and why?

Will the ideal collaboration only be a “time & expense” reimbursement collaboration where both get reimbursed for their time & expenses they incurred and then they share the margin equally…How would you like to share your business and margin in such case?

Devesh Dwivedi

Experienced Management Consultant

This is not as difficult a question as it seems. A very wise man, that I had the pleasure of working for, once told me something that changed my life…

“You don’t get what you’re worth. You get what you negotiate.”

Unfortunately, people continually compare themselves against others and worry about how their compensation stacks up against the other guy. They somehow take it as a given that the money they earn is directly tied to the value that they provide or their value as a person.

My wife worked in a job where she almost felt like she was robbing the company. She was making more money than she had ever made before and was incredibly happy. Then she found out the the slacker that sat next to her made 20% more than she did. Suddenly, the salary was unfair and she became a disgruntled employee. So what changed? Was she doing any more work? No. Was she making less money? No. Did her job change in any way? No.

So…what’s my point? There is no hard and fast rule for dividing up the revenues. I’ve seen account execs that work their butts off for 10% and they’re incredibly happy and wealthy. I’ve also seen lazy “do-nothing” reps that demand 60% or more and feel like they aren’t getting their share.

Personally, I think that the “hours” split is a silly one. If an AE can close a multi-million dollar deal in an hour and maintain it with a phone call per month, they provide the exact same value as the AE that has to sit on the account for hours per day. Similarly, a developer on the ground may work 80 hours a week, but piss off the customer with a bad attitude, miscommunication or broken code. You could use hours as a starting point (ie: “it would be reasonable to expect this to be a xxx hour commitment”) but I certainly wouldn’t use actuals.

My general rule of thumb is to simply ask each what their expectations are (hard dollars….not percentage of the pie), find a viable middle ground and try to keep 20-30% back for regular bonuses or for adjustments based on effort and complexity (difficult client that requires more hand-holding…excessive hours….etc.) . It’s more difficult when you’re one of the people in the mix. But you can still do it with customer satisfaction surveys or by just sitting down with folks at the table to discuss contributions. It’s funny how much more honest people will be about their contributions when they’re sitting across the table from one another trying to figure out how to divy up the money. It *does* require a certain amount of maturity in all parties. But if you have consulting professionals, that maturity is usually there (to some extent).

When it comes to professional networking, what do you prefer quality or quantity?

Devesh Dwivedi

Experienced Management Consultant

It’s important to get out there and talk to people (quantity) in order to find the people that you really connect with (quality). The more people that you encounter and interact with, the better your pool of quality contacts will be.

With that said, it’s difficult to maintain a good relationship with your network if it grows too large. You’ll have to judge for yourself what that balance is.

How honest does one need to be about salary history?

Specifically, when salary raise is one of the important reasons behind new job? Can your new employer ask for your past Pay-stubs to verify your salary?

Devesh Dwivedi

Experienced Management Consultant

There are very few things that an employer can’t ask. However, you’re not obligated to answer and they aren’t obligated to provide you with a job offer.

If you’re uncomfortable with the request, say so. If you’ve lied in the interview, you’re screwed. If you accept a job offer, they’re likely to insist on the salary confirmation as a condition of the offer and I know that I’d consider it a deal breaker if I found out that a candidate had lied to me.

You can try a couple of strategies:

1) Provide your current salary, but indicate that your primary motivation for changing jobs is money. Clearly state why you feel that you deserve more money/more responsibility (new skills, experience, certifications, training, etc.) and that you can do the job that they’re recruiting for. They’re unlikely to “low ball” you, since you’re demonstrating that money will be a factor in retaining you.

2) Tell them that you are uncomfortable disclosing financial information during an initial interview, but will gladly provide them with the information if and when you get to the offer stage. This essentially shuts down the discussion but shows that you’re not going to hide the information.

I’ve successfully used both strategies. The second was because I was taking a significant pay cut to get into a lower stress job. But I was worried that I’d scare them off if they knew what I was making. Ultimately, they never asked for the salary confirmation. They’re just as likely to assume that I was making much less, though.

I attended your session on Portfolio management at Symposium last month. It was a very informative use of time. You mentioned using drivers and categories for demand management and I was wondering if you could provide me some more detail?

Kulasekhar Jayaraman – via email

Thanks for the feedback. The session was a lot of fun and I really enjoyed the discussions.

The Work Types and Drivers approach is a compromise that we came up with to address the disconnect between the nature of a work request or project and the motivator for the request. We were having continual debates about “discretionary” vs “non-discretionary”, BAU vs KTLO, etc. By implementing this dual category model, we ended up with a way of tagging projects in such a way that we could map a project to any set of definitions or criteria that we needed to. It provided the right level of detail to be able to provide the engineers, executives and finance with the appropriate split and sorts that they needed.

Here’s the summary:

Work Types

Keep The Lights On/Operational Support/Core

Technical Continuity

Business Continuity

Minor Enhancement (Discretionary)

Major Enhancement

We’re struggling with how to compare different projects for prioritization. Do you have any advice for objectively assessing a proposed project?

PMPat via email

Those of you that have followed me in the PMI forums know that I’m a huge fan of Karl Weigers. In a prior company, my team adapted one of his requirements tools for objectively assigning a score to each project proposal. A sample of the tool is attached. Remember to work with your business partners to determine how to tailor it to your needs.I would also recommend assigning a relative weight to each line item. But even without that, it still provides a rough rating and assessment.

I hope that this helps to get you started. Drop me a note to let me know how you make out.

Deploying a Material Requirements Planning (MRP) or Enterprise Resource Planning (ERP) system is often hailed as a transformative leap for businesses. But let’s not sugarcoat it: the road is rocky, and failures are all too common. From ballooning costs to frustrated employees, these projects can go sideways fast. Here’s why it happens — and what you can do to prevent it.

1. Not Defining Requirements Early and Comprehensively

Let’s be clear: you can’t build what you haven’t defined. Companies often dive into system selection without a crystal-clear understanding of their high-level needs. The result? A system that may look shiny but doesn’t fit.

What to Do: Before evaluating vendors, nail down what the system absolutely must do, the business processes it supports and who is in a position to make the decisions around those psocesses. Skip the nitty-gritty for now; focus on the big “what” rather than the “how.”

2. Skipping Proper Vendor/Product Evaluation

Vendors can be persuasive, but charm doesn’t solve process misalignment. Picking a vendor without scrutinizing how their product aligns with your actual needs leads to customization hell. A few dozen checkboxes isn’t an evaluation, that’s just the initial screening, but it’s where many organizations stop and base their final decisions.

What to Do: Vet vendors rigorously. Insist on demos, references, and concrete point-by-point proof of alignment with your requirements. Detailed walkthroughs with your data and test cases are essential. Don’t discount a vendor because they can’t do it “your way”, but look at how feasible it would be to do it “their way”.

3. Leaving Out the Real Experts

Senior leaders often make the decisions, leaving out the people in the trenches who actually do the work. This disconnect guarantees overlooked details and unmet needs.

What to Do: Engage frontline employees early. They’ll pinpoint issues you didn’t even know existed.

4. No Neutral Contract Negotiator

When requirements are fuzzy, contracts turn into black holes of vague deliverables and runaway costs. Without an objective third party, it’s a battle of conflicting interests. The vendor doesn’t understand your business and you don’t understand the tool, so you absolutely need someone in the middle to help connect the dots. A third party who is an expert in the space can help set process, milestones and expectations that will protect both parties from costly overruns

What to Do: Bring in a neutral expert to mediate contracts, scope, and expectations. It’s money well spent. Be careful to plan and negotiate around worst cases and not just a blue-sky implementation.

5. Skipping “How Does It Work” Training

Most organizations jump straight into mapping gaps and customizations without first understanding the logic behind the system’s design. That’s like trying to remodel a house you’ve never walked through. The systems you’ve chosen has almost certainly been used by hundreds or thousands of customer before you without making your specific changes. Find out how. You might learn a better way.

What to Do: Train key stakeholders on how the system works out of the box. Learn its strengths and quirks before deciding what to tweak. Focus on how you can support your business with the OOTB system and not on how you need to change the system to support your business.

6. Dragging Legacy Baggage Into the Future

If you cram old data and outdated processes into a new system, don’t be surprised when it breaks or becomes a transformation nightmare.

What to Do: Bring only what’s essential: customers, suppliers, catalogs, inventory, GL balances. Run parallel systems temporarily to organically close out open transactions in the old system and phase out old workflows without chaos.

7. No Dedicated Implementation Team

Part-time attention yields part-time results. Delegating implementation to people already swamped with other responsibilities slows everything down and almost gaurantees a long drawn-out process. Competing priorities draw focus from fully analyzing and understanding the issues and impact fast decision making.

What to Do: Assign a full-time team with decision-making authority. Let them focus exclusively on the project.

8. Lip Service from Leadership

When a crisis hits, “top priority” projects can suddenly become afterthoughts. That sends a loud message: this isn’t really important. Additionally, changing business process will inevitably meet with resistance. You absolutely will need to change your business to be successful. Any customization that you allow will set a precedent for more customization and exponentially increase your risk of breaking OOTB functionality and impacting your upgrade paths.

What to Do: Leadership needs to walk the talk. Keep the team shielded from distractions and support them when business process changes meet resistance. Make the business work on adapting the business processes to the OOTB product and treat customizations as an absolute last resort. (see below)

9. Customizing Everything

Trying to replicate your old system in a new one defeats the purpose of upgrading. Customizations are expensive and risky and should be avoided at all costs. Full leadership support on this point is critical (see above)

What to Do: Start with out-of-the-box functionality. Test workarounds before jumping to customizations. Less is more.

10. Chasing “Best-in-Class” Tools

The “best” tool for every function often leads to a Frankenstein’s monster of disconnected systems. An MRP/ERP deployment is the perfect opportunity to centralize data and workflows under one umbrella and start to eliminate “one-trick-ponies” from your environment.

What to Do: Prioritize OOTB functionality and native integration. A “good enough” tool that fits seamlessly beats “best” tools that don’t talk to each other.

11. Micromanaging Vendors

You hired experts, not interns. Hovering over their work wastes your time and erodes trust. It also reduces your ability to hold them accountable when you don’t allow them to manage their own work and deliverables. Nothing will invalidate a fixed-price contract faster than micromanaging your contractors.

What to Do: Set clear milestones and hold them accountable. Then step back and let them deliver.

12. Too Many Cooks (or Vendors)

Multiple vendors mean more handoffs, miscommunication, and finger-pointing.

What to Do: Consolidate vendors wherever possible. Designate a single “general contractor” to manage the project and map out the lines of communication and accountability. Not everything needs to flow through you.

13. Treating Testing as a Formality

Rushed or superficial testing leads to faulty assumptions, wasted effort, and costly rework. Using “any available warm body” to do testing instead of trained/skilled testers will gaurantee that your testing is superficial. Testing is an overlooked professional skill and not something that everyone is capable of.

What to Do: Put skilled testers in charge of the process. Test early, often, and thoroughly. Validate assumptions at every stage.

14. Ignoring Data Quality

Bad data is like bad fuel — it gums up the works. Poorly cleansed legacy data leads to errors and inefficiencies.

What to Do: Audit, clean, and validate data before migration. In most organizations, this will be a significant effort. Make this a separate project if needed. Remember that a new system isn’t going to magically fix bad data.

15. Poor Change Control

Scope creep and endless revisions are the death knell of many implementations.

What to Do: Establish a solid change control process. Evaluate every change request for its impact and necessity. Track the reasons for the change request to better understand how to improve future requirements, product selections, testing and implementations

The Bottom Line

Deploying an MRP/ERP system is no small feat, but failure isn’t inevitable. By addressing these common pitfalls head-on, you can save time, money, and sanity. The key? Planning, communication, and a relentless focus on doing things right the first time.

What challenges have you faced during an MRP/ERP deployment? Let us know in the comments.