RFP Part 2

In my previous posting, I expressed my view that the prospective vendor should be willing to participate in demonstrations geared to highlight specific functions or tasks. This time I'd like to expand that thinking.

In a traditional RFP, you provide a list of required features and functions. The potential vendors review the document and reply with an equally tedious document wherein they state what their solution does. If they have need for further definition, they send a request for information back to you and we start going back and forth until the particular issue is defined to the satisfaction of all involved.

This dance is repeated with each of the potential vendors you invite to bid on your project. Very time consuming for all involved. Of course, if you had brought on a consulting company for this process, they'd be willing to run this process for you; of course, you'd be billed for their time and efforts.

I've seen this process on several occasions where the RFP took on a life of it's own and the customer lost valuable time and money while the consultants and vendors went to the dance.

So, how do you get through this in a more efficient manner? There's a few things that you can do:

1) Do a very good job when you define the deliverable. Your RFP document needs to be very clear, contain no ambiguities and be realistic. Don't develop the package in a vacuum; enlist the cooperation of all departments who will use or bene3fit from others use of the solution.

2) Your consultant (if you are going to spend a few million dollars and/or change the way your business functions, you really need to bring in an expert) needs to understand the project; more than just understand it, they consultant needs to be fluent in speaking to vendors about your organization and the project.

3) Be prepared to push the vendor into demonstrating key functions early on. You just may be able to reduce the list of potential vendors by asking them how they intend to address specific issues.

Let me offer an example that illustrates that third point. A few years ago I worked on an ERP refresh project for a fairly large construction company. At the time there were 72 packages available that were potentially a fit for the client. It could have been a daunting task to process RFP responses from even half those on the list.

To reduce the list we first eliminated those packages that did offer certain processes we needed to cover. Next pass we removed those vendors who were not currently supporting firms of a similar size and market niche. Finally we sent a package to each of the remaining vendors an invitation package. We identified our team, the client and our goal. There were a few vendors who declined gracefully, admitting they didn't want to pursue the project at that time.

After 3 passes we had a field of 12 to work with. I felt that this was still too many so we developed a suite of specific tests; unique tasks that had we knew to be problematic. My thinking was that if they can't address these, we were no better off going with them than we were in keeping the existing package in place.

Of the 12, we dropped as they couldn't handle some of the payroll tasks we identified. Letting them back out of the project early on saved us both time and money.

Managing the potential vendor list early on shortened the project schedule by at least 3 months. We were able to keep the client's energy focused on planning for the migration and ensure success.

To summarize, the RFP process shouldn't be a long, drawn out affair. You need to clearly define the goal, communicate the details and work to narrow the list of potential vendors a quickly as you can.

ERP Selection and the RFP Process

ERP Solutions and the RFP Process

I was reading a news article that a friend had forwarded me; a note about a recent court ruling. The English High court had ruled that a software liability clause was not ‘reasonable’. (http://www.channelregister.co.uk/2010/05/12/red_sky_liability_ruling/). Seems the software company had inserted a clause into the contract that said the customer could not take action against the firm for poor application performance.

While the customer has an expectation that the application would perform well, one would wonder what expectations were set for performance and by whom? The court ruling focused on the applicability of the clause and correctly (at least I think) ruled in favor of the customer in this case, it is not reasonable to require a customer to live with a poorly written application when trying to run a business.

Now, what has this to do with the RFP process?

Plenty.

Under the traditional RFP process, the customer should ask to see a demonstration of the software running in an environment comparable with their current environment, if possible. That is, if Joe’s Manufacturing Company was going through a refresh of their ERP, they should be able to see the proposed solution running within a similar environment with similar data they are running with currently.

Based on my experience, this key task is either omitted or glossed over quickly. Vendors don’t want to invest the time and effort to prepare such a test and most customers don’t understand how to go about creating a test sample of current data.

In the referenced case, there was a vendor demonstration that was attended by several employees from the customer’s organization. The documents don’t indicate who was in attendance (what role did they play in the execution of the job?) nor where the demo was hosted (did it run on a vendor provided server or was it installed on the customer’s servers?).

Vendor demonstrations are frequently scripted affairs that are designed to highlight the end user experience. I’ve sat through many of them over the years and have seen some vendors put the applications through the paces while other stick to a script and do their best to control the “show”. I’ve also seen demonstrations that were truly smoke-and-mirrors; the demonstrated app was a set of screens that looked like the app but were not much more than a slide show.
I’ve written a few RFPs over the years and have found the most effective way to manage the demonstrations is to write the rules in the RFP. If the vendor doesn’t want to participate, he’s taken himself off the list.

John’s RFP Tips - The Demo –

You need to add a statement in the RFP that ways that, in order to be considered, the potential vendor will need to participate in demonstrations at 3 levels:
1) System overview may be conducted on vendor provided servers. The customer will bring in end users from the applicable departments to view the demonstration, which needs to cover all major elements that are part of the core package.
2) Subsystem demonstrations using customer provided questions, scenarios and sample data. For example, if the application handles payroll, the potential customer will need to experience the set up, update and paycheck processing for sample employees.
3) Total system demonstration. The customer needs to provide a sample set of data that would be required to work through all components of the app. The system needs to be exercised to the point where reports and results can be compared to expected results.

I use 3 levels as it provides a convenient way to stop, review results between demonstrations and eliminate those vendors that don’t have a product that would be a fit.

Unless the vendor either has something to hide or doesn’t think their application can do the job, there is no reason they’d not want to participate. The results from all demonstrations and tests needs to be documented and used to support the eventual decisions on selection.

Business Meeting Etiquette

A few days ago I participated in a business meeting. I was with other members of our organization as we went to a client's office for a review of a project. Normally these meetings are conducted using a conference call bridge and we're at our own desks. We had asked for an on-site meeting so that team members could spend some time getting to know each other.

So, the teams assemble in the customer's conference room and the meeting begins. We had distributed ourselves around the table, mixing in our team with the client's team so that we avoided the "us verus them" seating arrangement. Our team had also left the laptops back at home; writing pads and pencils were the tools of the day. We had prepared in other ways, as well:

1) We arrived 10 minutes early.
2) Even though we came in 3 cars, we all walked in together.
3) The senior member of our team made the introductions.
4) When shown into the conference room, we spread out around the table, not congregating at one place.
5) We waited for the client's senior member to take a chair before we all sat down.

These are unwritten rules to be followed when you go and visit the client. Remember, you're only there because he trusts you with his business. You need to show the respect due them.

Now, there are some things you just don't do in a meeting:

1) Don't read your e-mail during a meeting and never answer e-mail either.
2) Don't answer your cell phone, should it ring. You should have turned it off when you arrived.
3) Don't IM your coworkers, no matter how important it is./ Excuse yourself from the meeting if you need to speak with someone outside of the room.
4) Whether you're the guest or the host, never yawn, no matter how boring the meeting is.
5) Never stare down a coworker if he should say something you disagree with. Take it up with him afterwords but not in front of the client.

The meeting I went to came off pretty well. There was only 1 person there with a laptop; yes, he was working on e-mail while we wee discussing the project schedule. While he was trying to impress with his multitasking skills, he wasn't successful. I know he was working on e-mail as I had 3 in my mailbox when I get back to my office. All 3 were sent during the meeting and had nothing to do with the meeting content. To make things worse, things covered in the meeting apparently did not make it into his action plan.

Bottom line, the traditional face-to-face meeting is reserved for special events these days; it's expensive to bring teams together when there are more efficient means of conducting meetings (conference calls, collaboration web tools). When teams come together you need to make the most of the time. You need to make eye contact, express your self clearly and develop some rapport with your counterparts.

Prepare for the call, review your notes with your team and be ready to discuss and propose solutions.

That's my view...

What if I don't make it in tomorrow?

Most of us go to work, day after day, never thinking about not being there. We really don't give much thought to what happens when we aren't in the office; after all, if we are ill or on vacation, we'll be back in a few days.

What happens if we don't make it back in for an extended period of time? What happens if we just don't come back?

For most of us, it's not a problem. Our job will be there, whether or not we occupy that cubicle. If the company needs a person to fill out the form or type in the details of purchase orders; someone else can probably be identified to fulfill the task, should anything happen to us.

Now, if you're the manager, the question of whether or not an employee shows up on Monday morning is important; the manager is still going to have to deliver the work. It's times like this that documenting all aspects of an employee's tasks becomes very important. And there is the fall down; for most of us, the job is documented in the body of an HR job description, maybe a page in length. Detailed task documentation and procedures are found in the book that came with the software.

I'm suggesting there are 3 reasons for well written job descriptions:
1) The job is well defined. The employees will know what is expected of them. The documentation provides a tool by which their performance is measured. When the description is written (and annually reviewed) the manager knows the job and how it fits within the organization.

2) Your job is well defined. A manager is there to lead the team and the manager is only as good as the poorest performer on the team. Your boss will gauge your performance by your team's ability to get the job done. If you are confident that your team knows how to perform and does it well, you look good.

3) Finally, you answer to someone, whether it be a manager at a level above you or maybe to an executive. You should have a clear understanding of your position and it should be documented in detail.

Simple as that.

Good procedures will carry the day in the event someone on the team doesn't make it back in. This includes you, the manager.
.

Thoughts on Disaster Planning

With the recent tragedies in Haiti, there will be a number of articles in the technology press about disaster planning and recovery. Over the next year there will be a lot of activity as businesses jump start third DR planning. And, unfortunately, many of these plans and programs will be put aside a year from now and, once again, American businesses will not have a recovery option.

This posting is not about developing a DR plan for organization. To develop a disaster plan, the business needs to commit both the time and the resources to the project. The business needs to commit more than just the IT team to the project because DR covers more than just IT. A good DR plan covers the entire organization, provides for business continuity.

Rather than going into a lengthy discussion of a DR plan, we're going to go through a list of items that should be in place today. Some items on the list should be self-explanatory while others are on the list based on my own experience.

Communications. Immediately after the disaster, management needs to assess the impact of the disaster or tragedy on the company. A key resource to any company is the workforce and after a tragedy there needs to be a plan or a process in place that facilitates inventory of that resource. Within the company, there should be a list, a telephone roster, which can be used to take inventory of your staff. An administrative staffer would start by calling key people on the list, department heads for example and they would in turn contact people underneath them keep track of who they were able to find and report this information back to the staffer who initiated the phone calls. These calls would also be used to pass on information to the workforce. Once management knows where everybody is they can get all of that the right people to reopen offices, relocate staff as needed or anything else that had to be gone.

Such a list needs to be distributed managers and maintained on a regular basis. It goes without saying that the list needs to be hard copy; chances are that when you need to access the list your computers will be down.

Documentation. Most of the documentation we work with on a daily basis is maintained on a computer, be it on the wiki, and intranet, or some other electronic means. In the event of an emergency situation, however, there are some items that you need to have a hard copy and in a safe place. My short list is as follows:

• Names and phone numbers of department heads
• Names and phone numbers of service and support organizations that I deal with regularly
• Names and phone numbers of corporate security staff
• Names and phone numbers of my primary vendors
• Because I have worked in IT for years, I would always include anup-to-date inventory of my data center. This includes the servers, network gear, telephony, storage, software licenses and any related hardware, software and reference material that I need to restore services.

Once again, in a disaster you might not have access to my computers so this data should either be on hard copy or on a CD.

The information that I've listed above needs to be kept current and available. My personal recommendation is that the data all be stored on the CD, copy to multiple CDs. Distribution as follows:

• One copy should be sent along with the off-site data storage
• One copy should be given to senior management, to be available to them should anything happen to the manager.
• One copy is stored at the manager’s house a small fireproof box.
• One copy is stored the home of the next senior person on the staff.

Finally, there is usually a list of key passwords and accounts (sys admin and other key administrative accounts) should be written down and given to a senior executive or legal counsel and stored in a safe place. Once again, this information could be needed to recover or re-create services and systems. Putting the data in the hands of the executive or the legal counsel, in the event that the manager was not able to participate in recovery, provides the organization with the information it needs to move forward.

I'm sure that there are those who would say there is no need to go through the steps, that redundant systems and well-designed infrastructure should withstand most disasters. Unfortunately, the tragedy of Katrina, Haiti and the World Trade Center have demonstrated the need for such preparation. It isn't enough for a manager to keep his department running on a day-to-day basis; the manager needs to look to the future and plan for uncertainty.

Meetings - Success comes from preparation

Meetings – Preparation makes the meeting

I’m a project manager, working in an Internet related business. Much of my day is spent working with clients and internal support teams as projects are brought together. To put it more simply, I host a lot of meetings.

Now, I’ve been sitting through business meetings for a long time and I’ve experienced good ones and bad ones. Both the good and bad ones have a common trait. The best meetings are a result of great preparation while the bad meetings have little or no preparation.

The agenda should be treated as a script for the meeting; the host needs to ensure that the subject matter is covered and that any follow up tasks are clearly defined. In preparing the agenda, the host needs to let the invited participants know what the meeting is to cover; what roles and responsibilities are defined and/or delegated and what follow up is to be taken. The preparations also need to address the time allotted for the meeting; is there sufficient time for all the items on the agenda?

In the last week I had the good fortune to be invited to a really good meeting as well as one that needed more preparation.

A client had asked to come in to the office and discuss the engagement. The request had come in the form of an e-mail sent to the appropriate members of the account team. In his note he covered, in 3 sentences, the subject of the meeting, time table and the potential outcomes that were to be discussed.

At the meeting he presented his situation, covered the time table and added some additional information that helped support his proposed solution. In less than 20 minutes, all the required conversation was completed and we were working on the solution.

I’m very impressed with the way the host prepared for the meeting. All the participants knew what was to be discussed before hand and were able to respond to his proposals right away. When the proposal was reviewed, all participants went back to their desks knowing what needed to be done and when the customer anticipated final resolution.

Later in the week I was participating in one of those monthly staff meetings that business seems to thrive upon. The host didn’t provide an agenda so we went into the meeting without any clue to the topics that were to be covered. To add to the uncertainty, the invite was for 90 minutes.

The meeting ran just under a half hour; we were shown an overview of the subject matter. There was nothing made available that we could take away from the presentation and review.
In my view, the meeting was not a good one at all. The participants took 90 minutes out of their day and were not prepared for the material presented. No clear statement nor detailed procedure or plan presented that would cover the tasks involved. No doubt there would be additional meetings to cover these details.

Getting back to the preparation component of the meeting, we should do a better job when pulling people in for a meeting; spending the time to get the material assembled and presented before hand leads to a successful outcome.

Just my view.