Feed on
Posts
Comments

Recall the post about improving Vendor written SOWs? The message was to first document your requirements and second ensure there was a thread from Requirements to the Work being performed by the Vendor. Note: this doesn’t just apply to Vendor written SOWs but your own as well. Now, let’s take that concept of creating a thread another step – threading requirements to test cases.

For every requirement, there must be a test case to validate the requirement  has been delivered and it functions as required. And vice versa, the test cases created must align with a requirement, else why were they written – wasted effort, wasted dollars. If the numbers are not very large – not a lot of requirements, a single tester, short testing period – the record keeping is manageable with basic tools and without becoming too sophisticated (word processor, spreadsheet). But when requirements number into the hundreds or thousands, a test team of more than one person, testing which will last for several months, time to move on to more sophisticated processes of testing and methods of record keeping.

To start with, it is highly recommended to number your requirements. This makes the record keeping and reporting simpler to manage. As an example, TR001 for Technical Requirement 001, FR003 for Functional Requirement 003, etc.

There are tools that align to this discipline and can make the job easier for you – tools that permit recording of Business Requirements, alignment with Test Cases, test results, the ability to produce a variety of reports on test results and even a test results dashboard.  The benefits of centralized tools are that the Quality Assurance / Testing team, the projects managers and any other stakeholders invited to monitor testing progress can do so by viewing the testing dashboard at their discretion.

If you don’t have the tools or the budget, roll your own. While this will require a tad more manual effort, the discipline can still be applied.  There is the option to use a spreadsheet, or if the mood strikes you, create  a database, which would provide the ability to produce a broader range  of  and more flexible reports.

If you are fortunate to have the budget to purchase tools, or would to know what to budget for, there are a number to choose from.  There are tools to document requirements, test cases and defects, and that provide the thread across them all. There are also guidelines for integrating tools from different vendors, if that’s what you have inherited. We suggest performing a search on the following tools (Mercury, ClearQuest, RequisitePro, TestDirector, WinRunner, LoadRunner) to find out what is available.

Happy Testing!

As a Consumer and Customer in the marketplace, you make purchases based on requirements – on your needs.  “I just tore the sleeve on my suit – better go out and by a new one.”  You also have expectations of the product as well, which you don’t necessarily think about when you are out shopping. “I will be able to raise and wave my arms to catch somebody’s attention and the stitching in the sleeve will hold and not split.”  An expectation yes, a requirement really, but as I said probably not something you think about. (Ok, you’re probably going to try that test the next suit you buy, so here’s another – squat down to ensure the waist and seat are comfortable when assuming this position – and that the slacks do not split).

Gathering requirements from customers on a project is likely welded into your methodology. But what about EXPECTATIONS?

What is the value in extracting expectations? the risk in not? Customers will have expectations,  very likely uncommunicated needs (so far) for the product or service you are asked to produce.  I challenge you to draw out those expectations, and turn them into requirements. After the formal requirements gathering process is completed, politely ask the Customers assembled before your “We’ve documented requirements, are there any expectations you have of what we are producing for you?” And the expectations will surface, features the Customer just, well, naturally expected to be there. And after you have recorded them on the flipchart, politely mention to the Customer, “These are great. They really sound like requirements though. Do you mind if we add it to the list of requirements and process accordingly?” Follow your process for managing requirements – the expectations are not delivered for free. If the Customer expects to see those capabilities in what you are building, they must be prepared to pay for them, in terms of both Cost and Time.

I can hear some naysayers now – “Scope Creep, Scope Creep”.  This is not scope creep – this is MANAGING EXPECTATIONS.  Otherwise, you may not deliver what the customer … well, expected –  requirements plus expectations. If the customer expects to see it, it must be evaluated, prioritized and funded if it is to be.

And then you can give yourself a pat on the back – because you identified these expectations early up front, and were not surprised by the Customer months laters at the Acceptance meeting.

Happy Holidays and all the best for the New Year! This will be our last post for the year, we’re taking some time off, see you in a few weeks in 2010!

A project team is collectively tasked to deliver … something.  It could be a new building, an IT application. And when the project is closed down, the project team will be disbanded. They will *not* be the caretakers, the people required to look after what was delivered and what must now become operational.

So look at your project and think – who will be the Operational Caretaker for what you are delivering? The project team is the conscience for the Customer’s needs during the project – who is the conscience for the Customer’s needs after the project?   Obviously, it behooves you to speak with these people before the project is finished. To really make your project shine, though, engage them early – right at the beginning of the project.

My experience is the people accountable for  ongoing care eagerly participate in my project meetings. They also represent the Acceptor – the person who will accept the product or service produced by the project team and will be responsible for the operation of the product or service.  Sometimes they are smiling at these meetings, which gives me the message they have probably been ignored in the past, engaged at the 11th hour and surprised  – not pleasantly – by what was being handed over.  And who likes these kind of surprises?

I’ve also experienced PM Methodologies that formally did not engage the Operational Caretaker – the Acceptor – until well into Execution. We have ignored this and approached those managers early during Planning. They have to live with what is produced. They have knowledge that is incredibly valuable in helping the project team define a solution that better lives with the Customer. What is the point in delivering to the Customer’s needs, if it turns out to be a pain to live with and take care of afterward? And who better to provide that knowledge than – the Acceptor, the Operational Caretaker.

In your project, identify who the Acceptor is for what you are producing – it is not necessarily the person paying the bills, or the people using what you have produced – and engage them as early as possible in your project to really make your project shine.

To LOI, or not to LOI

Contracts can take time, a long time, to negotiate. And often, there is legitimate pressure to expedite, with diligence, the engagement of the Vendor. This is where the Letter of Intent (LOI) surfaces as an option.  An LOI is a type of letter issued to a Vendor to confirm the awarding of a contract and pending the signing of formal contract documents.  It is a commitment document. Note that permitting work to start before the contract is signed is not recommended as the Customer is without full protection at that point until the contract is signed. But frequently, work does start before the contract is signed. For this discussion, we assume the LOI is a legally binding document, to the extent that the Vendor incurs costs.

Do not assume the LOI can be completed faster than the contract itself. LOI authoring may expose risks that can only be resolved with a contract; hence its application may be limited. Let’s consider four IT related items for which contracts are regularly negotiated: consulting, software, hardware, and network.  The question to ask yourself prior to proceeding with an LOI – if we are unable later to reach a contract, what is the impact of unwinding any work already performed?  The previous order of IT products is significant – it is in increasing complexity of unwinding the work performed, which might occur as follows:

Consulting – Customer requests the Vendor to stop work immediately. Customer pays for work performed, Vendor delivers products produced to date. Assumption: this is for human resources effort only. An LOI is feasible.

Software – Customer immediately stops using the software, uninstalls the software, returns or destroys any materials received (CDs, manuals). Customer pays for any value received (training). LOI feasible.

Hardware – becomes a little stickier. Deconfigure and ship the hardware back to the Vendor. Potentially restocking and shipping charges. LOI feasible.

Network – to obtain the best rates, agreements are typically for several years. If the Vendor has committed several years worth of capital and expense resulting from the LOI, who owns the liability if a contract is not then completed? The LOI effort will likely stall at this realization, unless either the Vendor or Customer is willing to assume full liability for the network facilities if a Contract is not completed. LOI not highly recommended in this scenario – you might want to just proceed straight to the Contract negotiations.

There we have it – a few thoughts on whether to proceed with an LOI or not when the Customer is putting pressure on the PM to engage the Vendor more quickly.

A Statement of Work (SOW or STOW) is a narrative description of the work to be performed, as part of a project. Very useful for work performed under Contract by a Vendor. When multiple vendors are engaged to deliver a project, multiple SOW will be produced. If the project involves only internal resources, an SOW or something very similar (as scope document) is still highly recommended.

Who authors the SOW? Well, the party doing the work is the most reasonable candidate, therefore when Vendors are engaged, they will very likely author the document. And this is where risk lies, when the Vendor is focused on the work and the cost of the work, and not on additional factors critical to the customer, like requirements.

Consider a sample SOW that only shows the activities to be performed by the vendor and their related cost. The big risk in this document – the SOW does not show what requirements are being met. It may not even explain exactly what the customer will have after the work is completed. Think of an SOW for a customized application that elegantly describes the finished product, but lacks a clear thread back to what the customer asked for. Without the thread, the Customer is doing mental gymnastics deciding if what the Vendor is describing “fits the bill”.

And what “fits the bill”  is described in the requirements. For large projects, it is highly recommended to author separate documents for Business, Functional, Technical Requirements as needed (things will get approved faster). For smaller projects, it is acceptable to document all requirements within the SOW.  To establish a thread between the requirements and the work being performed by the Vendor, create a table that lists  Requirements as row labels, and Work Activities as Column Headings. Code your requirements (BR001, BR002, TR001, TR002) and your work activities (V1WA001, V2WA003), to eliminate confusion relying strictly on word descriptions of each. For each requirement, then ask the Vendor – which work activity is delivering this requirement? Do not be surprised if you find the work activities do not align 100% to the requirements, i.e. there are missing activities or activities that don’t align to a requirement.

The value of this discipline it that your end up with no or fewer surprises, because of the diligence you have applied in aligning the work activities with the project requirements. And it’s not nice to surprise your Customer (except on their birthday).

When you hear ‘learning curve’, you’re probably thinking it means – how fast can you learn something. And there’s a built-in assumption – that once you’ve got it, you won’t forget it. Once you as an individual learn something, you won’t forget. Once your company and the team you work with learn something, you won’t forget it. Well, not necessarily so. Events can occur that lay waste to efforts to learn new processes, and new skill sets. We’ll identify these negative events, and suggest how to mitigate their impact. Note, the guidance in this post applies equally to projects and the operational side of the business.

Learning Curves and Processes

Many companies (unfortunately not all, I have found) maintain accurate documentation of their processes and methods, for their project and operational activities. As the teams repeat these processes and gain more experience with them, the expectation is that the cost, resources, and time required to perform these processes will decrease. This is the premise behind the Learning Curve (or Progress Functions), applicable to both people and organizations. It has been observed in practice where repetitive processes exist, as far back as the 1930’s where it was heavily documented in aerospace manufacturing. Basically, as we obtain more experience reusing existing processes, costs decrease – right? Or, is your answer “I don’t know”, or “No”? Is it really just theory then?

Let’s review some  fundamentals, conditions that must be in place to obtain Learning Curve benefits, and how to identify causes behind loss or lack of learning and what to do about them.

Interpreting a Real Live Learning Curve

LearningCurve Figure 1

Learning curves reflect a reduction in direct labour or cost as the number of units delivered increases.  Figure 1 shows an 85% learning curve (click on the diagram to see a larger image). Each time the number of units produced doubles, direct labour or cost is reduced by 15%. Beyond the 64th unit, the hours required start to level off.

Benefits do not happen by accident!

There are some conditions behind these results:

1) Best practices are identified

2) Best practices are documented

3) Best practices are communicated throughout the organization, and

4) Best practices are applied consistently (on each project, on each operation).

Learning curve benefits are not guaranteed. Practice does not make perfect – “perfect practice makes perfect”. A quick question: can you locate the project management or operational ‘best practices’ documentation in your organization? Are they applied consistently?

“Not to worry. We are managing our costs as well as anyone else,” you may say.  Surprise! Most likely, your costs were going down and may now be going up because of ‘other factors’ at work.

LearningCurve Figure 2

When Learning Takes a Holiday or Regresses

The Learning Curve in Figure 2 shows learning not only stopped but regressed, as the organization or individual returned to earlier levels. “But I followed the conditions,” you might argue. “What happened?” Change, that’s what happened.

A closer look at best practices required to achieve Learning Curve benefits include:

  • Personnel are trained and retained.
  • Processes and technology remain relatively unchanged.
  • Time is provided to deliver within quality specifications.
  • The Work Environment remains relatively stable and effort and energy are committed to best practices.

What happens when these factor are missing:

  • Personnel – Resignations and downsizing result in learning walking out the door and a ‘hiccup’ in the learning curve. Note: this will impact many organizations, as an unfortunate consequence of downsizing due to the recent economic crisis.
  • Process and technology standards – a change can render past learning useless. Retraining is required. Time to deliver increases; costs increase.
  • Time – reducing available time usually causes quality to suffer. And rather than the ‘desired’ beneficial learning, coping and firefighting behaviour may evolve, and sadly, more highly rewarded.
  • Work Environment – Re-organizations, inadequate tools can sap energy required for the application, monitoring and control of best practices.

Many of these assumptions are also interdependent. As you replace team members with new personnel, as you downsize then re-engage, the work environment changes. New personnel require training, time to adapt, and consequently, the project will require more time to deliver.

figure 3

How then, can you remedy your specific situation? A Cause and Effect analysis for Learning Has Stopped (Figure 3) will provide insight. Many of the stated causes can potentially be behind your situation.

What happens when change is constant?

LearningCurve Figure 4

Figure 4 shows a scenario where an organization or individual encounters change on a regular basis. An elongated sawtooth pattern emerges. Learn, unlearn, learn, unlearn, etc. Considering the pace of change today, this happens in many organizations. In some industries, it is worse than others.  Consider project management in the IT field. Constantly changing software tools (C++, Java, BI, ERP), delivery environments (mainframe, PCs, web) have historically produced the sawtooth pattern. And with Web2.0, SaaS, Cloud Computing, Virtualization, smart phones, etc. this will continue. The ability to estimate accurately becomes a challenge. Projects take the hit on missed deadlines, increased costs, descoping or reduced quality.

Getting the most from your Learning Curve

So in the midst of this sea of chaos (mild, or otherwise), what can you do to better your competition with regards to making your projects and operations successful and maximizing benefits gained from learning curve experience?

  • identify, document, communicate and consistently apply your best practices.
  • invest in revisiting your best practices
  • be selective in implementing change. Consider how that change will impact your project management learning curve. Strive to identify value in implementing the change.
  • accept there will always be change and we will be continuously learning and relearning.

Happy learning! And, do you have any ‘learning curve’ experiences to share?

It’s an often heard mantra – “be lean and mean”. An admirable objective – for the operational side of the business driving for reduced costs, increased revenue and increased profits. But, this attitude does present risks for the project side of house.

One of the consequences we’ve observed of lean, and sometimes, too lean organizations, are programs and projects started with insufficient resource capacity. Lean and mean can also result in little, if any, spare capacity for emergencies. Overtime will then be used to keep things going. When along comes an unplanned project (or two, or three), the situation is then fodder for overtime becoming a regular occurrence, projects taking longer than expected and stressed out employees.

In the spirit of embracing Project Management best practices, though, and being proactive (not reactive), what can we do to eliminate or mitigate resource capacity issues, and ideally, even prior to project startup?

Let’s first examine a real-life case study and the reactive approach it forces, and secondly, let’s see some proactive responses to mitigating such occurrences.

Project Work Sometimes Plays Second Banana

My Lead Business Analyst had just returned from a canceled workshop: “So we had booked the morning with them to document and validate their existing processes. They were great all last week, now this morning they don’t show up. They say they’ve got other work to focus on, and they don’t know when they can meet with us again. We’re not going to make our milestones this way. They won’t commit to anything – so I’m escalating.”

Well, the first thing I did was thank her for coming to me immediately. If I don’t know about your problems, I can’t help you solve them. Let’s nip them in the bud.

In situations like this, a ‘lean’ organization might consider engaging temporary contract resources in lieu of full-time resources to solve this problem. It will help but it will not necessarily provide the best solution to the problem. Care must be taken in engaging contract staff when full time staff, the Subject Matter Experts (SMEs) of the organization, is what is really needed to ensure a complete solution and a successful project. Full time staff / internal SMEs have knowledge of the company’s business that a temporary or new employee will not, and can better predict the potential impact a project will have on the company. It is the fulltime staff alone can provide that last bit of polish and completeness to Project Management documentation – the Business Case, Project Charter, Business Requirements, Work Breakdown Structure, and Risk Management plans. Now, can you cultivate SMEs from temporary staff? Yes, and if you have available contract staff you’ve used before congratulations. Otherwise, realize this requires knowledge transfer of your operation to the newbies brought on board and unavoidably the time of your internal SMEs.

Why is the Project Coming in Second?

Back to our case study. The Project Manager is forced to be reactive but is empowered to remedy the situation (PMs – you have as much power as you believe you do). What can be done? Start by meeting with the Functional Managers of the unavailable employees.

  • Ask – what work has displaced the project commitment? How is this higher priority?
  • Ask – was this a unilateral decision on the part of the employee, or under the direction of their Functional Managers, or other Senior Stakeholder?
  • If the former, the Functional Manager has an issue to resolve with his/her staff unilaterally deciding what they will work on, and not escalating workload issues.
  • If the latter, the issue is more serious – the lines of communication are broken, the project priority has been downgraded in somebody’s eyes. Time for a meeting with your Project Sponsor to exert some influence and get the project back on schedule. Be prepared for these discussions. Document the impact of the forecast delays on the Project Schedule and Project Costs within a DRAFT Change Request.

In hindsight, a lean organization plus unplanned projects plus overloaded SMEs are not ingredients for project success. But it happens often, so be prepared to deal with it. Nothing is constant but change in areas like market share, financial situations, strategic direction which spawns or impacts projects. Even if you are not a Project Manager, you are going to unavoidably be involved in projects during your career – as a Team Member, as a Functional Manager, Project Sponsor – and it behooves you to mitigate situations like our case study as much as possible.

So you’re not the PM? What can you do?

“But I’m not the Project Manager, what can I possibly do?” you might ask. “Isn’t it the PM’s job to take care of these problems?” Remedy them after the fact, perhaps.  But before the project is initiated, before the PM is assigned, while the project portfolio is being established, surprise! It is not the Project Manager, but the other Project Stakeholders in the company who, on an ongoing basis, are positioned to be proactive and help the organization mitigate project resource issues.

  • As a Member of Senior Management

Take action by investing in an Enterprise Project Management Office to provide Portfolio Management. This EPMO can provide advance warning to business units of future programs and projects. This provides lead time to plan for additional resource capacity and establish the proper funding and infrastructure to support the project. (Example: with a project portfolio of $10 million, knowing that IT in your organization typically represents 60% of project budgets and your funding for IT projects is currently $4 million, you have very quickly determined there is a shortage of IT resource capacity.)

  • As a Resource Manager

Be aware of the company’s ambitions re: Programs and Projects, i.e., the Project Portfolio. Be aware of Enterprise Architecture and Technology Directions, and the skill sets this will demand. Monitor available resource and skill set capacity, and escalate issues to Senior Management. (Example, if there is a market shortage of skill set in XYZ Technology, advise Senior Management that this must be factored into high level project timelines.) Establish contingencies; project delays, resignations, leaves of absence, and surprises will impact available skill set capacity.

  • As a Functional Manager

Take action by ensuring each member of your staff has an up-to-date description of their operational and project roles and responsibilities. Apply this information to explore options when capacity issues surface. Be prepared to re-assign responsibilities, have some resources fully dedicated to projects while others focus on normal business operations, or hire temporary resources to perform the mundane administrative functions normally performed by your staff.

  • As a Project Team Member

Take action by keeping up-to-date documentation of your roles and responsibilities. This provides planning information when you are asked to take on additional work for a project. Example: if you already at capacity, what can come off your list and be re-assigned, or delayed, or even canceled?

Review the previous bullet points. Notice how much power resides in the various people in the company i.e., the future Project Stakeholders, even before the Project Manager is assigned, to proactively mitigate resource capacity issues.

And if you are the PM…

Now, if you are assigned as the PM (hopefully at the project’s start), what can you do to proactively mitigate a recurrence of our real-life case study?

  • Engage the support of the organization’s Resource Manager to source project team members. To the best of your ability, identify the Roles and Responsibilities, and Skill Sets required. Enlist your Project Sponsor to validate that the assigned internal resources have the required skill sets and are not just warm bodies coming off the bench. Remember, ‘availability is not a skill set’. If the company does not have a Resource Manager role, 1) engage your Project Sponsor to help – a must if you are a PM freshly arrived (new hire or contract) in the organization. 2) prepare for a possibly lengthy process of negotiating with Functional Managers for capacity from their people capacity to work on your project.
  • Gain commitment from the Functional Managers and their designated staff for their participation and their time on the project.
  • Assign each Team Member to evolve and document their Roles and Responsibilities for the project. Meet together with the Functional Manager to review and commit to this document.
  • Engage the Project Team members in defining the project work. This will also define the tasks in the Project Schedule that reflect the commitment previously agreed to. Obtain approval of the schedule from key Stakeholders.
  • Communicate and share this information with the broader project team. Everybody, including Project Sponsors, will then know what commitments have been agreed to. Publish the documentation in the online Project Notebook and advise all Stakeholders where this is located.
  • Produce and distribute a Project Organization Chart to all Stakeholders.

Notice a common thread in the above points – DOCUMENT AND COMMUNICATE!

With regards to being ‘lean and mean’: the dictionary defines “mean” as “selfish, cruel, spiteful, and malicious”. We respectfully suggest this is not an attribute you want your organization and project teams to aspire to. Let’s use ‘lean and keen’ instead. Keen – “enthusiastic, intense, marked by intellectual quickness”

The Bottom Line

For organizations, it is possible to be lean and keen (not mean), proactive, and better prepared to tackle your project portfolio. With all potential project Stakeholders embracing our recommendations, they will be better positioned to respond to project resource demands, even those that flare up unexpectedly. For Project Managers, you can take action to mitigate problems at the beginning and during the project. You do have the opportunity to evangelize the recommendations put forth in this article, and position your organization to be lean and keen.

There are probably as many answers to this question as there are people who have worked on a project, funded a project, or been the benefactors (or victims) of a project. Your comments welcome; please indicate the viewpoint you are responding from – team member, sponsor, benefactor/victim. Here are a few to start.

  • completes on time, on budget, as scoped.
  • the project is over and everyone wants to work together again.
  • may not be on time, on budget, as scoped, and the customer is delighted.
  • a positive work reference from the project sponsor and/or the project manager.
  • benefits to the business are realized. This may take a while.
  • the customer is willing to serve as a reference account.
  • success criteria documented in the project charter is realized.
  • the handover to the Operational team is a smooth transition.

What do you think – what makes a project successful?

A critical part of staffing a project team involves conducting interviews. After describing to a co-worker how several colleagues and I ask candidates to ‘show me’, by using a whiteboard to show what they know versus just telling me in words, my co-worker said “That’s Entrapment!” What do you think?

The first time I saw this practice applied was by a Customer who managed a network services group.  My first surprise was to discover that this employer required candidates to pass a one hour English proficiency exam. This was an activity, I was informed, to mitigate previous negative experiences where new employees didn’t make it through their probation period because of the inability to communicate using basic English, creating a need to repeat the hiring process. The candidates had been advised this test would be administered.

During the interview, the manager informed me he would probe to see how well the candidate’s knowledge aligned with the claims in the resume. Nothing sinister, or tricky.  For example, he would draw a basic network diagram with an obvious error in it, and ask the candidate to point out what was wrong (i.e., he’d put a router on the wrong side of the firewall). Or, he would ask the candidate to draw a basic network configuration for a corporate campus, or to link up multiple campuses. Things a Network Planner with the years of experience claimed by the candidate must be able to do. The interviewer discovered that at times the results were less than expected and the candidates were rejected.

A PM colleague who is an expert coder applies the same technique during his interviews. He would ask candidates to go to the whiteboard and at a high level, sketch out basic program structure, or sketch a few lines of code to describe basic functions (i.e., in Java or C+ depending on the requirement).

Now, least you think asking candidates to whiteboard during an interview is out of line, today’s interview coaches will advise you that, as the Interviewee, this is an excellent technique for standing out amongst other candidates – bring a marker to the interview and use the whiteboard to diagram your responses!

While interviewing for Senior Business Analyst positions, I’ve asked candidates to sketch out the most complex solutions they  have ever analyzed. I don’t need them to fill in the words on the boxes and give away proprietary information, or identify the company.  I’m hoping to see a Use Case diagram, ‘swim lane’ diagrams, or a data model.  A candidate drawing a HIPO diagram lacking even conditional ‘if’ statements doesn’t speak “Senior BA” to me.

“That’s Entrapment!”, my colleague said. What do you think?

RFx Lessons Learned

The wise management of procurement of products and services will include one or more of an RFP, RFQ, and RFI. This post will discuss Lessons Learned during these processes. The books and courses at your disposal offer great advice but don’t necessarily address every situation that may surface, thus this post, which will evolve and grow.

Q – if a response arrives early, days before the cutoff date, should I open it immediately and have the team get started on the evaluation?

A – Never! A member of the evaluation team upon reviewing the material, may begin speaking about it, and the information *could* find it’s way back to one of the other respondents. Never create the opportunity for what may appear to be unethical behaviour. In this area of business and awarding dollars, “Not only must one be pure, but one must appear to be pure”.

  1. Keep the response under lock and key until the closing date and time.
  2. At the closing date and time, with a witness, take the responses into a meeting room.
  3. Record in a log, who has responded, what time the responses have arrived.
  4. Open each response and log the contents (binders, CDs, other) in the log.
  5. Record what softcopy was provided by the Respondent and the media- CD, USB Key, email or secure access to a vendor server.
  6. The log sheet is to be signed by yourself and the witness.
  7. Save a copy of the log sheet into your Contract Management System.
  8. Save a softcopy of the responses in your Contract Management System.

Q – any special considerations when asking a respondent to provide a reference?

A – Require the following in the response: in the same industry as your company, similar size, similar corporate structure, in the same city (at least nearby – not halfway across the continent), and available to speak with you during the life of your RFx evaluation process.

But don’t stop there – inform the Respondents you plan to visit at least one of the references, for a meeting of approximately 2 hours to gather real life experiences with their product. And if a site visit is not possible, use a conference call as an alternative, providing the reference site with background information on your company. And no, the Respondent/Vendor does not sit in on the visit, or the call.

Q – noted that there are many books out there, as you said. However, they are not cheap. Do you have any recommendations to get a quick return?

A – There are many different subject areas that can be covered. A good general book, that covers negotiation ploys/tactics, and contrac wording is “The Contract Negotiation Handbook” by Stephen R. Guth. I will also recommend visiting his blog – the link is on the sidebar to the right of this screen.

Q – my counterpart on the other side of the negotiations regularly makes the comment “Noted” when I make a statement, observation, or counteroffer. Why does she do this?

A – this is an excellent tactic for saying something without committing to anything. One of the most dangerous things to say after the other party has spoken is “ok” – this denotes agreement with what was said, which may not be at all what you want to communicate! In casual conversation, think how many times we might say “ok” to mean “I hear you – continue”. If you wish to communicate the same meaning during negotiations, and you feel you just have to say something, say “Noted”, or “Noted – continue”. It is also a good word to communicate “I heard what you said, I recognize it, and I am writing it down.”

Q – my supervisor instructs me to have the Vendor sign the two copies of the contract first, and then have our internal approvers sign the contract. Is there really any difference?

A – There is risk in having the Vendor sign the contracts as the last step to closure. Unfortunately, the contracts might get misplaced or the urgency for final approval may wane. Having the Vendor sign first ensures that you, the Customer, will have control over the final step to obtain closure on the documents, not the Vendor. And you will be in a position of power to politely remind the Vendor to get the signatures on  the Contract.

« Newer Posts - Older Posts »