Posts Tagged Project
A reputable supplier
You are transitioning between services or systems. You have a good contract. You have a strong project team. You have selected a reputable supplier. What could go wrong?
Almost by definition all transitions are subject to increased risk. This may be due to lack of familiarity with the new supplier and their service or software; it may result from ambitious timescales; or it may arise from resource limitations and budget constraints. Whatever the reason, it is certainly the case that something can and probably will go wrong: with the deliverables, with the delivery, with the relationship between you and your supplier.
In Getting System Implementations Right and Prerequisites For successful HR and Payroll Implementations I discuss strategies to minimise the risks within organisations for transitions of this kind. In this article I look at ways to address the risks which arise specifically from your supplier and your relationship with them.
As a first step towards the management of your supplier it is important to identify their potential weaknesses. During the sales process you should ask your supplier to assess their own weaknesses, both past and future, and how they intend to address these in relation to any arrangement with yourselves. An independent assessment of your supplier’s weaknesses should also be undertaken through research, trawling the internet and speaking with existing customers. Weaknesses you are likely to find will include:
- Diminishing commitment once the sale is agreed and the contract signed
- Poor relationship management
- Erratic communication, both internally and with their customers
- Inadequate resourcing, in terms of availability and skills
- Failings in the product or service delivered
- Insufficient implementation support
- Tardy operational support
- An unhelpful corporate ethos
I will discuss these, and the measures you can take to reduce their likelihood and impact, below.
In seeking to manage your supplier it may not be weaknesses solely on their part which need to be identified and addressed. No organisation is perfect, and you will need to mitigate against weaknesses of your own. Examples might be:
- Insufficient resourcing of supplier management
- Unfocussed communications with your supplier
- Insufficient clarity of purpose
- Inconsistency in negotiating issue resolutions
- Lack of forcefulness
Once you have identified the potential risks inherent in your relationship with your supplier or in their delivery of product or service, you will need to put in place actions or plans to mitigate against these risks.
Supplier commitment and motivation
How can you ensure the continuing commitment of your supplier after the sale has been agreed? Once your contract with your supplier is signed, the charming and effective sales wing of your supplier’s organisation will hand you over, as a new project, to their delivery team. In many organisations what happens next will have little impact on the staff with whom you were to that point involved. The sales team will turn their attention to new prospects and new sales, and your new contacts will have a less compelling (i.e. no longer commission driven) motivation to meet your needs.
You may also discover that you are one amongst many projects which the delivery teams have in hand, and not necessarily one with the highest priority. Larger and more assertive customers will take precedence over smaller or less demanding newcomers; customers with issues will always jump the queue; and your needs as an organisation are now in the hands of people with whom you have not yet developed a working relationship.
Pre-emptive measures to ensure the commitment of your supplier after this handover takes place need to be included in your contract. Ideally, the contract should include:
- Delivery targets
- Implementation timescales
- The supplier’s detailed confirmation of the extent to which they can meet each individual requirement in a contractual requirements document or ‘statement of work’
- A supplier-incentivising payment profile
- Penalties for supplier non-performance
- Insurance against subcontractor non-performance
- Defined implementation consultancy and support
- Defined system and DBA training
- A detailed Support SLA including escalation points
- System performance guarantees
- An agreed change control procedure
- A supplier/client conflict resolution strategy
- Defined skill sets and experience levels for each of the areas in which consultancy will be provided
If any of these elements are missing, then the time to revisit them is now. It is unlikely that your supplier will agree to enhance their contract with penalties for non-performance, but they should be willing to document the levels of service to which they will commit, and the measures they will take should failings arise.
To further motivate them, ensure that senior supplier representatives attend Steering Group or Board level meetings where the progress of the service or software implementation is reviewed. No one enjoys publicly representing an organisation which is providing a poor service, and the supplier’s representative will be motivated to see that the job is done well simply through being faced with the prospect of seeing you again in three or four weeks’ time.
You should also ensure that the supplier recognises that your motives and theirs are congruent. You want their software or service to be successful, and it is useful to emphasise to the supplier your willingness, if the implementation is successful, to publicise this. If your supplier performs well you should make it clear that your organisation will be in the vanguard of singing their praises: a reference site for potential future customers and an example of the best practice use of their system or service.
For most suppliers, the bottom line is the bottom line. You need to be able to maintain financial leverage up to the last possible moment, since, once the bulk of your payment has been deposited in their bank account, your supplier’s interest in you may mysteriously diminish. This applies both to the whole implementation or any part of it. Where possible, never pay for any deliverable unless you are sure that the deliverable you are paying for is one hundred per cent complete. Again, where possible, never pay for completed deliverables if other deliverables which should have been completed from the same supplier or their subcontractors are still outstanding. In addition, you should attempt to delay payments until the end of a period of time sufficient for resolving teething problems. Ideally, the basis for these activities will be confirmed rather than restricted by your contract.
If you are lucky enough to have a contract which imposes penalty clauses for poor performance, make sure these are kept in mind and regularly reviewed.
Finally, connect and communicate with existing users of the system or service at an early stage. Their experiences and support may prove a useful asset in your management of your supplier.
If a supplier is providing you with a product or service over an extended period of time which is important to your business or project, then it is important that you maintain both a good and a firm relationship with that supplier. But a relationship cannot exist where there is no continuity of contact, therefore a degree of contact, determined by the importance attached to the supplier’s contribution to the project, is a key initial requirement to managing your supplier.
It is beneficial if the supplier’s representatives like you, but this is by no means necessary; it is far more important that they feel the need to keep you on-side through providing an excellent service.
For an important supplier this may mean a daily telephone conversation, face-to-face meetings every week or every fortnight, and a senior representative from the supplier attending service review or board meetings every three weeks or month. It is important that the meetings with the supplier be friendly, honest and problem solving, rather than blame directing, but it is also important that the supplier be kept aware that penalties – where available – will be incurred for non-performance or failings in performance. You must also make it known to your supplier that they are expected to give warning of potential failings in delivery or service well in advance, in order that mitigations can be planned and undertaken in good time.
Clear escalation paths need to be agreed for the different types of issue that might arise (e.g. commercial, contractual, service or product), but informal lines of communication should also be nurtured. This can be achieved through attendance of user groups or conferences provided by the supplier, through informal relationship building and through such things as connecting at a senior level via LinkedIn.
A conflict resolution strategy should be documented and agreed with your supplier, and this should include the involvement of managers in both organisations who are not direct participants in the relevant implementation or project, thus permitting greater objectivity when resolving issues.
It is certainly important to keep the relationship sweet; but this is trumped by the need for firmness, honesty and a positive problem-solving approach.
As a general rule it is safe to assume that your supplier, after sales, will be a poor communicator, both internally and with their customers. Sales staff are selected for their communications skills, but mid-level delivery managers are usually selected for their technical or area knowledge – and it is likely your supplier’s delivery team will be drawn from a technical background or from work areas centred on a narrow business focus.
To address this your project manager and other involved managers should be briefed to pre-emptively encourage good communication. Ensure progress reports are shared with your supplier; and request a similar level of communication in return. As noted above, ensure regular contact, by phone, skype, email and face to face. Make sure you have an ‘open door’ policy with your supplier which works in both directions; and quickly escalate your concern if areas of communication appear weak.
At the beginning of your project (ideally during contract negotiations) ask your supplier to advise what consultancy or training is likely to be required at each stage of the software or service implementation, and ask them to provisionally book experienced staff to provide these services at these times. Ask your supplier to be proactive and to pre-emptively assign resource to your implementation, especially if they reach preferred supplier status. After contract signature, follow this through for each phase of your implementation, checking your supplier’s resource allocation for all remaining phases. If this isn’t pursued vigorously you may find yourself being provided with stopgap or inexperienced staff, while the best staff are allocated to other, more demanding clients…
Request the CV or skill set of every person or role the supplier intends to deploy to meet your requirement, and ensure that your organisation is not used as a training ground for untrained staff or recent recruits.
Finally, make sure your supplier is aware of your expectations of their consultants, in terms of behaviour, dress, and time spent on site. Some suppliers may ‘try it on’ and factor the travelling time of their consultants into your working day. Ensure this is nipped in the bud early, before a pattern is established.
Failings in product or service
No matter how good your supplier is, there will always be failings to a greater or lesser degree in their delivered product or service. And no matter how well you get on with your counterparts in your supplier’s organisation, these failings should be closely monitored, documented and communicated. You should never leave your supplier in the position of being able to say, ‘Well, you never told us anything was wrong…’
To support this, you will need a clear requirements specification or ‘statement or work’, which should have been compiled prior to – and used as part of – your contract negotiations. If this is not available, then your project manager and area experts should be tasked with producing documentation along these lines, against which to measure deliverables.
A test plan should be developed for every anticipated software release, upgrade, patch or change in service. As a recipient of such changes you should always assume that your supplier has inadequately tested the change. This is a characteristic universally shared by suppliers, no matter how well established or how good their reputation.
Prior to final payment for the implementation of a product or service, check for full compliance with the original agreement or contract. The supplier will invariably treat payment as acceptance, and subsequent fixes, even if implicit in the contract, will be slow in coming or charged as out of scope.
As noted above, where possible, and if your contract permits it, retain financial leverage…
Some elements of a new software or service provided by you supplier – particularly those which involve third parties – will involve significant delivery lead times. At the beginning of your project or implementation request your supplier’s expert advice on the lead times for any key elements of your deliverable which lie on the critical path for delivery. Examples of these might be the setting up of servers or comms, or the delivery of specialist training. Sometimes it will be worthwhile asking your supplier to provisionally book or initiate these activities prior even to contract agreement, if the lead time involved might otherwise delay the start of your implementation.
It is important to assume – in order to minimise risk – that your supplier will be forgetful. On this basis your project manager or other involved managers should generate prompts and reminders to your supplier well in advance of any deliverables on the critical path, and ensure that confirmation of readiness has been received in return.
Rigorous recording of the implementation services (and all other deliverables) provided by your supplier should be maintained at all times, independently of your supplier’s own records. Your supplier, no matter how well intentioned, will certainly bill you for every demonstrable deliverable, but they cannot be relied upon to keep a scrupulous record of deliverables or services they have failed to provide.
The above considerations will also apply to the operational support provided by your supplier after your software or service has gone live. A continuing relationship should be nurtured at a senior level; clear communications and reporting should be maintained; and all failings or faults should be documented, reported on, and promptly escalated. The transition from implementation to operational support is similar to that from sales to implementation, with a similar risk of diminishing engagement by the supplier. It is important to proactively address this through your service level agreement and regular service reviews.
Ethos and attitude
Finally, in terms of supplier weaknesses, it is useful to understand, and, if necessary tackle, your supplier’s ethos and attitude. No matter what short term economic necessities are faced by your supplier, it will always be to their long term benefit to keep their customers happy and demonstrate their adherence to the principle that ‘the customer is always right’. Sometimes it is worth reminding suppliers of this fact.
You want the service you have bought… but in fact you want more than this. You want, as an organisation, to be treated well and with respect. You want to be treated as a valued customer, no matter what your financial value to your supplier or your size in relation to their other customers. And you need to make this known to your supplier from the moment you commence contract negotiations though to the end of your contract.
Resourcing the management of your supplier
All of the above activities of course require an investment of time and commitment on your part. This is true of all aspects of a project, and projects succeed or fail on the basis of the resource invested in them and the commitment made to them at a senior level. Your investment in supplier management therefore requires its own business case. If you are dealing with a small supplier whose contribution is minimal, then you may fine tune the resource you devote to managing that supplier. For very large projects, supplier administration may be farmed out to teams or departments who specialise in procurement, contract and supplier management. Alternatively, responsibility for coordinating supplier management may fall to a project manager or other senior involved managers. For smaller contracts or suppliers more junior staff may be assigned this responsibility. But at whichever level you choose to aim your supplier management, this should be a strategic decision on the part of your organisation – and the risk mitigations detailed above should all be considered, even if they are only selectively implemented on the basis of value and cost.
Communicating with your supplier
It cannot be assumed that your supplier’s contacts, once you have purchased their product or service, will demonstrate good or even adequate communication skills. As I recommend above, these skill may need to be provided proactively by your own organisation, and allowance should be made for this.
Forcefulness, consistency and clarity of purpose
Finally, in dealing with your supplier, you need to be clear about your objectives, reasonable in your expectations, unemotional, candid, forward-looking and professional. You should allocate your relationship management to individuals who are not easily overawed by senior supplier representatives. It is important to keep the relationship sweet, but it is more important to approach your relationship with a great deal of backbone, expressing your position frankly and not allowing suppliers to provide a service or product that is anything less than excellent. Excellence is what your supplier will have promised when striving to win your custom and, through rigorous supplier management, excellence is precisely what you should compel them to deliver.
In summary, you can gain the most from your supplier if you manage them closely and strategically. To do this you need a strategy for supplier management in general, and to tailor this to each specific supplier once you have ascertained their strengths and weaknesses. Expecting a supplier to manage themselves to your advantage, particularly if they have large numbers of other customers or clients, is unrealistic. If you approach your relationship with your supplier proactively, planning for the worst but asking for the best, this will give your relationship with your supplier, and the software or service they provide, the greatest chance of success.
Luke Andreski PMI PMP
© 2013 Luke Andreski. All rights reserved.
In giving this article the title I have given it I might be accused of miss-selling… however, and quite unexpectedly, I find myself, if not exactly excited by, then at least seriously interested in, the topic of project filing.
A significant element of any project manager’s work is to collate, create, review and update documents which relate to the project or projects in hand. For this reason it is important that project documents are filed in an intuitive and sensible way, reflecting both the project management methodology being used and the life cycle to which the project adheres.
Currently I prefer to work with the Project Management Institute’s ‘Project Management Body Of Knowledge’(PMBOK) methodology, with its nine knowledge areas: Scope, Integration, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement. These need to interface with the typical life cycle of the projects with which I am currently involved: initiation; planning; analysis and design; system configuration; data migration; testing, documentation and the transition to operational live running. Then of course there are the pragmatic considerations of information storage and retrieval: What do you need immediate access to as soon as you open a project file? What folders will you need to access most often? Are there other areas of documentation or data which are not covered by the matrix of knowledge areas vs. life cycle? How can you ensure your file structure is intuitive and easy to adopt?
With all this in mind I have devised a project file and folder structure for use with both hardcopy and electronic filing which I have tested against the storage requirements of real project data.
This structure seems to me to work… but is it the best?
Take a look:
The Project File
Folder 1: Stakeholders and Contacts
This folder will include simple contact lists as well as stakeholder analysis and stakeholder management planning
Folder 2: Governance – Charter and Scope
This folder will include the contract, initial scoping documents or terms of reference, the project initiation document or charter, and any further detailed scoping. In other words, all the documents by which the project is initially defined
Folder 3: Project Planning
Once you have established the scope of your project – the objectives, requirements, outline timescales and budget – serious planning can commence, and this folder should contain not only the usual MSP Gantt charts but also meta-planning documents such as your plans for project management, for quality assurance, for human resource management, for communications and so on
Folder 4: Status – Activities Issues and Risks
To include status reports and updates, issue logs, risk logs and schedule variance
Folder 5: Status – Costs
This folder will include budget or project costs and utilisation reports, and earned value or other assessments of value achieved versus expected. The utilisation of third party deliverables should also be reflected here. This area is given a folder in its own right to reflect the importance of cost within most organisations
Folder 6: Change Control
To hold change requests, both pending and authorised. These, in conjunction with the data held in the Governance folder, define the project
Folder 7: Project Coordination
This folder holds the ‘project office’ type of documentation not already covered by the other folders: the agendas, papers and minutes for formal meetings(such as Board and Project Team meetings). Also documentation related to supplier management or the administration of supplier deliverables such as training and consultancy
Folder 8: Project Data
This folder holds the data associated with the life cycle of your particular type of project, e.g.
8.1 Analysis and Design
8.2 Infrastructure and system administration
8.3 System configuration and build
8.4 Data migration
8.5 Testing and quality control
8.6 Procedures, manuals and guides
Folder 9: Phase and Project Closure
To hold documentation relating to the closure of phases or the project as a whole, including the documentation of lessons to be learned
Folder 10: Miscellaneous
…because there will always be some documents which are impossible to categorise or which do not deserve a category of their own.
This is how I have begun to structure my project files. How have you structured yours?
Luke Andreski PMI PMP
I am a project manager with many years’ experience in HR and Payroll system implementations. I am in the process of completing my most recent contract for the housing and care organisation Midland Heart. After a one or two month break I will be seeking a new contract from August/September 2013 onward.