Project Management

Great Article on CRM Innovation by Gabriel Gheorghiu

I was impressed by a great blog entry about CRM innovation for innovation's sake on the TEC blog. You should have a look and check out some of the other entries. Great insight and information.


Beware of CRM Innovation for Innovation’s Sake

by Gabriel Gheorghiu


When I first wrote about the upcoming TEC CRM Buyer’s Guide focusing on innovation, I stated that customer relationship management (CRM) vendors can differentiate themselves from their competitors through innovation. But I also mentioned that innovative technology should not be embraced just because it’s new or cool, or  seems to bring the answers to your problems.

Innovation is great, but remember that innovative products can also bring challenges that your company might not be ready to deal with. So after all the excitement settles, here are a few things you should consider before adopting innovative technology.

1. New technology and old business logic can be a terrible combination. New programming languages and platforms can be used nowadays to create user-friendly interfaces, dashboards, and widgets to group and display information into a single screen, but this is not very useful if the data is not stored and managed based on business logic and best practices that make it easier to retrieve and analyze.

To avoid falling into the trap of acquiring new technology with old business logic, test it before you buy, and focus on the operations that you perform on a regular basis in your company. Sometimes the new interface is just another way to make the solutions look better, which may make it more user friendly and accessible, but may not help with important business processes and workflows.

2. Innovative technology doesn’t always fit well with your existing tools. If you found a great tool to gather customer feedback using social media, but you need to first export the results manually in order to import them into your CRM system and then analyze them in a separate BI tool, the whole exercise might not be worth the investment.

This pitfall can also be avoided by looking at the tools that the new innovative solution needs to integrate with. And start with the ones that are critical for your daily operations. Try to estimate the resources required for implementing and using innovative technology, as well as their costs, and compare them to the expected output. For instance, using a portal for account receivables may not help if your customers prefer to receive invoices by e-mail.

3. Innovative technology will always cost you something but return on investment (ROI) is always hard to calculate. Even when it’s free, an innovative CRM solution will cost you time and effort to test it, implement and integrate it, maintain it, etc. And it’s almost impossible to calculate ROI for innovative technology, because you don’t know what extra investments it will require in the future; it’s also hard to isolate the effects that innovative technology has on the efficiency of your company.

Adopting innovative technology will always entail risks, but you can limit them by using a phased approach: start by embracing the innovative technology for a few business activities that are important to you and only extend it to others if it proves to be really useful. A good practice is to first have a small team of motivated and enthusiastic people that will pilot such initiatives and then scale them to others if they prove to be efficient. Imposing the innovative technology at the enterprise level right away will most probably create disruptions, which will translate into indirect costs.

4. Innovation isn’t always a commitment for vendors. Your CRM vendor may not have innovation included in its long-term product map. For niche vendors, it gets even more complicated, because they might be acquired by larger companies, which will incorporate the solution into theirs and perhaps decide that future development does not necessarily focus on innovation.

Vendors with a proven history of innovation may be considered safer from this perspective, but the ideal way to address this challenge it to make sure that the solutions you use for CRM are flexible enough to allow you to integrate with others by adding or removing new modules and add-ons, develop new functionality, and keep the changes when your vendor changes its development strategy. Also, make sure you can easily get your data back when you decide to opt out of solutions that seemed innovative but aren’t meeting your expectations.

Embrace innovation, but never for innovation’s sake

A person can afford to spend hundreds of dollars for a new gadget just to be one of the first to have it, but companies cannot afford to invest hundreds of thousands of dollars and a lot of time in innovation without a strong motivation and analysis of the investments required. In other words, impulse purchasing of innovative technology will be much more costly for a company, thus the need for a more level-headed approach to innovation. Unless you are careful, you will end up investing a lot of time and money, not to mention the disruptions you may bring to your relationships with your customers and partners (e.g., some of them may not be ready or willing to adopt the innovative technology you find so great or others may not have the IT infrastructure to use that technology). Not to mention the false hopes that you can give them and the disappointment if you’re not able to deliver (e.g., if you build an online community, make sure someone will manage it, otherwise it can be worse than not having any).

Innovation for CRM, with its advantages and challenges, is described in more detail in the upcoming TEC CRM Buyer’s Guide, where I will be discussing cloud computing, mobile, social, and extended innovative technology for CRM. In the meantime, I welcome your thoughts on the risks of adopting innovative technology and the ways companies can reduce them.


Be the first to comment - What do you think?
Posted by admin - November 4, 2011 at 06:57

Categories: ProBlog, Project Management, Technology   Tags:

Contracts and Expectations in Small IT Projects – Part 1

Introduction – Fixed Price vs. Time and Materials

It is an axiom that businesses small and large consider IT projects high risk. Many have instituted policies requiring fixed price contracts, in order to minimize their risks. These same companies often do not realize that this policy creates a situation where engagements with their vendors become losing situations for each.

I contend that many customers and vendors share basic misunderstanding of the concepts of contracts, expecting the best of both fixed price and time and materials contracts. This first blog in a series will talk to some of the reasons why.

Almost every executive has a story of a project which started small and became a sucking black hole of time, resources and money. I have lost count of the number of these stories I have heard personally, on topics ranging from custom application development, to off-the-shelf implementation to web site delivery. While the stories differ in specific detail, the core elements remain the same:

  • We thought it was a simple project
  • The contractor/IT team/salesman told us it was straightforward
  • We did not think that we changed the scope during the project
  • We felt taken advantage of both during and after the project, if it ever finished
  • We did what we were told
  • The person responsible for the project had his/her career negatively impacted

The multiplier effect held true for these stories. For every first person epic I heard, there were tens of second and third person anecdotes. The grapevine is very fast, if not always accurate. How many times have you, the reader, heard the words, “Did you hear about … ?”

Not surprisingly, while companies still understand the need to have these projects done, they have and continue to push their vendors toward fixed price contracts. The ideas are basic and often reflect their own corporate processes. These include:

  • Risk aversion and reallocation
  • Payment for deliverables rather than effort
  • Cost reduction

For some projects, this can be an effective policy. Where customization and configuration is minimal, it can be effective to contract purely on the basis of deliverables. A sample in the IT world might include:

  • Computer setup
  • Network cabling
  • Server setup

The above, with a small number of parameters, are repeatable tasks. Once an image has been created and tested, computer setup effort can be predicted within a relatively accurate range. The same applies to cabling a building or setting up a server. Many companies provide fixed price estimates for these tasks, with constrained scope definitions in their contracts. Usually, these prices include a level of contingency to address the inevitable unexpected issues.

At its core, I propose that companies reason that if a vendor is proposing a solution, they should know exactly what it takes to deliver it. They should be able to estimate it in detail and if their estimate is incorrect, it is their own fault. The experienced and expert vendor should eat the extra risk, not the unwitting client.

Let’s look back at some of the core experiences.

Client Vendor / Consultant
We thought it was a simple project We told them, in person and in writing, that there was complexity to this project. They just could not seem to understand. Why hire a consultant when you don’t want to pay for consulting?
The contractor/IT team/salesman told us it was straightforward We gave them a range of samples of our projects from similar industries. They latched onto the smallest effort and cost, though their project was more complex and larger.
We did not think that we changed the scope during the project Every time we talked, the client wanted some additional customization, configuration, additional training or support. By the time we were able to understand what they actually wanted, rather than what they had said they wanted, the project estimate had grown. But they could not understand that what they wanted was not the same as what had been agreed to in the contract.
We felt taken advantage of both during and after the project, if it ever finished We felt taken advantage of during and after the project. They kept asking for more and saying that it was a part of their original expectations. But we were so deep in we could not afford to pull out.
We did what we were told They tried but even the most basic client deliverables required our assistance. The needed iterative discovery and delivery but did not want to pay for it.
The person responsible for the project had his/her career negatively impacted The client was not happy and refused to provide us a reference. In fact, when they talked about the project, they implied that we did not provide what we said and that our service was lacking. The account rep is on thin ice. The PM and the team received smaller bonuses.
It is even more vital to require fixed price and to determine processes which make it harder for the vendor to change the project price after the start How do we deal with them next time? They keep wanting more and making it harder for us to deliver. There does not seem to be any incentive for the customer to manage their own expectations or requests.
It seems unfair that we had to pay for change orders where the vendor did not always use all the estimated time. Amazing. When the effort exceeds the estimate, they want us to cover all the cost. But when it is less, they want to pay less. Don’t these people understand a fixed price contract?

Another axiom in the project world is that successful small projects require the same processes as successful large projects. Implementing an application or web site requires detailed understanding of business and technical requirements. It is rare when a customer is happy with a completely generic solution which does not account for their specific needs.

It is common for customers who think their projects are small to expect that the vendor will enter the project with an innate understanding of the requirements. After all, they have done similar project before. They often convey their requirements at a very high level or do not truly understand their requirements.

Often, the customer does not actually understand what they want until they have had the chance to see a prototype or beta version. They see the site or the application and suddenly understand that what they really wanted was … something more. And here starts the almost inevitable discussion of requirements and scope. The customer looks at the vendor and says something to the effect of “You should have known what we meant. If you want to get paid, you have to make sure that the deliverable meets our current expectations.” So starts, with a certain inevitability, the arguments over scope, cost, change orders, timelines, expectations, contract terms, payments, escalation and reputation.

Vendors can feel trapped by the customer’s contract requirements. They are forced to include increasing amounts of consulting in the sales process in order to be in a position to engage with the customer. But this effort grows harder to recoup, as most customers are loath to pay for time incurred before the contract is engaged. To recoup their efforts they are required include copious amounts of extra cost which the client will then begin to whittle down. Like all vendors, they fear the other guy coming in to undercut their offer. They go low, expecting to make it back in change orders. And the cycle begins again.

On top of other difficulties, there is a lack of understanding by many clients of the difference between a fixed price contract and T&M with a fixed cap. This will be addressed in future parts. Suffice it to say that there are few worse ways to engage with a client.

There is no complete solution to the issues inherent in projects, fixed price or T&M. However, future installments will discuss:

  • Expectations management
  • Effective contract writing
  • Proactive documentation and reporting
  • Contingency estimation
  • Vendor differentiation strategies.

Any insights or anecdotes you might want to provide can be included as comments to this entry, via the contact page or by e-mail to


Be the first to comment - What do you think?
Posted by Carey Miller - February 16, 2010 at 19:00

Categories: Project Management   Tags: , , , , , ,

Blog Recommendation – Dr. John A Estrella’s Blog

From time to time I tour the Internet, looking for things of interest. I found Dr. Estrella’s blog, of all things, via Twitter. It was part of a #FollowFriday recommendation.

I was not sure that would make a note of the blog here. It is interesting and concise but I was not sure how much new information it brought to me. Then I saw the entry labeled, How To Manage Bad News In Your Projects. It is a short entry, which I repeat here, linked to the original.

Three components precede bad news: target, trigger and tweak. By recognizing these components, you can easily manage most of the bad news in your projects.

If the monthly target is $10K and the expenses are trending toward $40K for the next three months, then the potential overrun is a trigger that should prompt you to tweak the situation. Inform the project stakeholders but be careful not to cry wolf.

If you’re able to steer the project towards a more favourable outcome, then you can report the good news. If not, then the bad news will not be a surprise to the parties involved.

Take a look at your current targets—budget, schedule or objective—and identity triggers that will give you adequate room to tweak the circumstances if needed. It is better to pre-empt than to be held in contempt.

I consistently preach transparency. Clients are never more angry than when bad news is delivered in the past tense. As the cliche says, forewarned is forearmed. It seems Estrella agrees, though I suspect we might have interesting discussions regarding actual use of trigger and tweak.

For that and other interesting entries, I suggest you check out his blog.


Be the first to comment - What do you think?
Posted by Carey Miller - October 16, 2009 at 11:39

Categories: PM Reviews, Project Management   Tags: , , , , , , , , , , , , , ,

Blog Recommendation – Preventing Project Failure

I came across a very interesting and insightful blog about Project Management and PM’s. Called Preventing Project Failure, A Practical, Usable Blog by a PM for PMs, I found it an excellent combination of objective and subjective information. The blogger is a PMP named Michiko Diby. Her LinkedIn profile is found at

Definitely worth a look.


Be the first to comment - What do you think?
Posted by Carey Miller - October 11, 2009 at 10:29

Categories: PM Reviews, Project Management   Tags: , , , , , , ,

The Sorry State of Project Managers and Business Analysts | CIO – Blogs and Discussion

Has anyone noticed how trivialized two supposedly critical functions in the IT world have become? I’m talking about project managers and business analysts. I always thought of those two functions as pivotal, as make-or-break activities on any development project. (Forgive me, I thought of them as maybe even more important than the programmers.)



Be the first to comment - What do you think?
Posted by Carey Miller - August 11, 2009 at 18:13

Categories: Project Management, ProServ Tweets   Tags: , , , , , , , , , , ,

Highslide for Wordpress Plugin