Print this page

Estimated reading time: 9 minutes, 36 seconds

Project Pitfalls

digging_a_holeI was involved in a lot of implementations throughout my career and can truthfully say that, although almost every one was different, there's commonality across them that can be exploited. I've mentioned in the past that most of the implementation work we did at my previous employer was related to customer EDI and eProcurement/marketplace connections, but that we also supported our nearly-all-electronic supply chain as well.

Those are definitely two points along the complexity continuum with respect to project work. For our supply chain, we had a limited number of transactions our supplier partners needed to support, we outsourced testing for new partners to a third party, our business side folks handled any non-EDI issues with the partners, and our part was mainly just getting them set up in SAP and monitoring the transactional activity.

On the other hand, the customer side was the 'wild west', with all types of formats, data communication paths, transactions, marketplaces, customer types, yada, yada, yada. Although the number of supply chain-related transactions exceeded customer-side documents, the overwhelming amount of implementation work was performed with customers. Lots of customers wanted to connect to us electronically, and we thought that was a good thing.

Since we did so much work on customer implementations, most of my thoughts related to projects are based on those interactions. I don't think there are any breakthrough insights here, but based on our work with several hundred of these I think the conclusions are pretty solid. So, without further adieu, here are some of the things that you need to pay attention to in the course of an implementation. They'll make or break your project.

  • Communication is an obvious one. This means all intra and inter-team communications, verbal, email, documentation, etc.must be timely, constant, and unambiguous. There are a few ways to guarantee this happens; we used a very detailed implementation process that had scheduled calls, checklists, and other activities that ensured communication took place between all parties. We even solicited feedback from the partner after the project was in place to help us uncover issues with communication.
  • Requirements: you need them, you want them, you better have them nailed if you want your project to succeed. Everyone needs to be on the same page with respect to what's going to be delivered, and changes once development starts should be few and far between. 'Scope Creep' isn't some project manager's goofy nickname, it's a painful condition that should be avoided at all costs. The implementation process mentioned above was designed to elicit and document all business issues and technical requirements for every customer-side project we developed. In many cases, requirements are straightforward and aren't an issue, but for our customer projects a dizzying array of issues related to our multi-channel business model had to be rationalized and agreed upon before we created our first map.
  • The timetable can be looked at as just another requirement, but it deserves its own discussion. If you've done a few projects, you probably have a good feel for how long they take and can establish milestones in your discussions with your partner. If you like, you can even use a tool like Microsoft Project to manage the work. Because business side people normally drove our customer projects, we were sometimes blindsided by date changes that seemed to come out of nowhere. Generally, pushing a date back wasn't an issue with us- we had so many projects in play that we'd just get another one started and juggle the work. Moving a date up, though, often caused problems. Typically, you have scope, resource, and time at your disposal in a project, so that when one changes one or both of the other two must be modified. In our case, when the timeline changed, scope never changed so we had to negotiate resource levels. That often forced us to go back to the business to stop work on other projects so the appropriate level of commitment to the new date could be made. Of course, we always pushed back on the partner to reconsider the date change requirement utilizing our internal business sponsor, but that rarely worked. I wish there was an easy answer to this, but there's not. However, if you have a standard process and business side involvement, you can usually work out a satisfactory solution.
  • Business-side support was a 'must-have' for us. That meant ensuring the sellers, the people who brought in projects along with their management chain, knew our offering, our process, our resource constraints, and the escalation processes to use with management for issue resolution. Without this, you wind up with commitments being made to partners that can be fulfilled, deadlines that can't be met, unhappy partners, and internal conflict. With it, you have world peace. You make the choice. Seriously, you can't afford a contentious relationship with people who generate work for you. You need colleagues on the business side that understand your work and can help you manage expectations with your partners.
  • Consultants can be helpful, or they can get in the way and actually hurt a project. They can be valuable to you to supplement your workforce, provided they have the necessary skills, or to do things that technically may be beyond what your team can do. Since our customer-side work was so complex from an analytical standpoint, we learned through trial and error which tasks could be 'farmed out' and which could only be performed by our people. Of course, engaging a consultant presumes you have the budget for it, which can be another issue.

When we worked with consultants with whom our partners had engaged, results were mixed. We had good relationships with consultants working on behalf of marketplaces, since they seemed pretty experienced and had encountered the questions we'd asked before. Our worst case scenarios occurred when a new partner would cede control of their implementation completely to a consultant who wasn't familiar with the types of business process issues we brought to the table. It's tough to do an end run around someone who's ostensibly 'in charge', but to succeed with the project you really need to get the business side people engaged on both sides to resolve questions. In almost every case where we had problems, it was due to the consultant not being familiar with the complexity of the business relationship the partner had with us and an unwillingness to seek help to answer questions. You need to be sensitive to their feelings for the good of the project, but the key thing is to get your issues resolved, whatever it takes.

  • Flexibility is always a positive. If both you and your partners can roll with the punches through the course of a complicated implementation, then many things that could derail it can be circumvented. Lack of flexibility has caused the demise of many a project through the years. What we found was that as the experience level and competence of your staff increases, they're better able to extrapolate and create win-win solutions. Less experienced people seem to be a little too dogmatic about what can and can't be done... they 'know what they know' and sometimes lack the confidence to think much beyond that. Until your newer people gain the necessary background, I'd encourage them to never say "no" without running the scenario by a more senior employee.

In dealing with partners who are unwilling to bend, it's difficult to address the knowledge level issue without generating hard feelings. When you reach an impasse, it's often best to get business side people involved to help work out compromises. Note that when you receive a mandate from a major hub customer who buys direct materials from you, there's usually very little leeway available. They've often built processes that are totally dependent upon automation and cannot accept outliers.

  • Level of partner commitment is another variable that can make or break a project. At my previous employer, implementation projects for customers would need to be justified and approved prior to us working on them. But the amount of actual throughput for the transactions we developed was highly dependent upon how much the customer really wanted to use them. That's one reason why we did so much up-front analysis- we didn't want to throw a lot of work into implementing a set of transactions that wouldn't get used. We'd often discover after the fact (and after researching why no traffic was passing through the connection) that getting the project implemented was part of some manager's objectives for the customer, but that actual usage didn't matter. Requiring an implementation and training plan for the customer prior to engaging in the project is one way of ensuring the connection will be used, but that's an extreme option. The best approach we found was to ensure the people who brought the projects into us were cognizant of the costs involved in a project and knew that it only made sense to bring us work that would be ultimately used.
  • Dealing with 'newbies' was always a trip. Since we were often the largest MRO supplier for our customers, we were generally one of the first companies they'd work with to automate their purchasing. This can be a blessing or a curse. On the one hand, they would often pattern their requirements off of our 'standards', so that made the maps easier to create for us. On the other hand, they sometimes had no concept on how long things would take and would be unaware of business process issues that would impact their project. We found that working with a newbie generally took longer than with a more seasoned partner, but that we often reaped the benefits of being the first one in.

There are a number of ways to define 'success'. If you have a mandate from a mega-retailer, success may just mean getting the work done and testing complete before the deadline. In our world, it was a little more nebulous..... was it meeting the agreed-upon timeline? What if the timeline was met, but the partner ended up not even using the connection? If you define it as 'meeting the business goals of both partners', that may make it a little more palatable if the requirement was part of a contract your company ended up receiving, whether the partner used the connection or not. However you choose to define it, realize that there are impediments lurking out there that need to be accounted for somehow. Our solution was a relatively tight process that recognized the risks and had steps built in to catch them early and bring them to resolution. That may be overkill for some groups, but the point is that you shouldn't be taken by surprise by anything that will put your project at risk.

As always, comments and suggestions are welcome. Feel free to write me at This email address is being protected from spambots. You need JavaScript enabled to view it.

Read 2253 times
Rate this item
(0 votes)