Blog Search Minimize
External Links Minimize
Pilot Synergy Blogs Minimize
May 11

Written by: Michael York
5/11/2011 6:25 PM  RssIcon

From my experience, there are a number of factors at play here and some things to consider when we find ourselves in this situation:

  1. First – remember vendors are not perfect.  They will often fail to deliver a perfect product on time and under budget (though this is possible).  When things start to slip and deliverables are substandard – it is vital to avoid the “blame game”.  We must continue to collaborate with the vendor to empower their success.  We stand to lose a lot if they default.
  2. As project managers, there are a number of “warning signs” that we can look out for. Of course, seeing these during the competitive procurement is best thus avoiding a bad situation altogether, but that often doesn’t happen.
    1. Vendors with mature business processes around IT should always employ a design phase where a trained “architect” is involved and working closely with the customer/business analyst.  This is even when no software development is necessary.  Vendors who do not use this practice are demonstrating a lack of process maturity which is a warning sign.  Insisting they “follow” best practices will usually not help since process maturity can’t be achieved this way.  (What to do here?  Be extra vigilant for the common consequences of an insufficient design and build extra contingency time into the schedule to handle this in addition to working through the deficiencies with the vendor).
    2. Vendors that provide overly optimistic project plans (or no project plan) are demonstrating a lack of “evidence based estimation”.  Evidence based estimation uses past performance to predict future results for similar work.  This is advanced for most vendors, but the alternative is to be more conservative with estimates than optimistic.  When you get a project plan that clearly does not show enough time for certain processes – this is a red flag.  Challenge the vendor (but remember paragraph 1) to get a feel for where their ability to foresee work is going wrong.  Be very careful about communicating an overly optimistic schedule to the business customer!  Bad news earlier on (when there is still time to react and overcome) is always better than later on.  It’s common to want to put off bad news but please resist the temptation. Set the standard early that you’ll communicate potential slips early and often.  There is a balance here.  Mastering it is challenging, but important.
    3. Be careful about painting the vendor into a corner when it comes to asking them when to expect a deliverable.  Vendors typically “aim to please” so if we are overly demanding on when we want something, the easiest thing for them to do at that instant will be to “promise” it by that date.  The trouble with this is that sometime it forces the vendor to put their process maturity aside to meet the deadline (which may still be impossible).  This will never result in a positive outcome.  It is important to ensure the vendor has ample time to meet their targets so they can follow their own processes and ensure a quality result.  Sometimes this means facing the fact the schedule will slip earlier on – but, as I said above, earlier is always better than later.
    4. Vendors can get defensive when they get behind!  We see this time and time again. The key is not to return the favor.  If they start pointing fingers it is usually best to acknowledge what they’re pointing out (usually a shortcoming on your part) and return them to a success vector. (I.e. How we can work together moving forward to achieve a successful result).
      1. Don’t forget about your project team in this respect as well!  Especially when they may communicate directly with the vendor.  If the project team is getting defensive then they will practically beg for this same reaction from the vendor in return.  Be sure to keep the project team on track and keep them with an attitude of collaboration and success.
      2. Of course, this also goes for the business customer!
    5. Cash Flow – Be careful when vendors promise more than they can reasonably deliver.  If they are trying to push up payment milestones in a way that is not in your best interest, this is a signal they have cash flow problems.  Why do we care?  If they can’t pay their staff they may see an even bigger resource problem since most people can’t afford to work for free or delay their compensation.  Keep an eye out for this since it can have an impact on your schedule!  In some cases there may be things you can do to help their cash flow (breaking Statements of Work (SOWs) down more thus adding payment milestones, etc).
    6. Vendors with good process maturity should employ the following core processes (no particular order):
      1. Change Management – A good vendor will have a robust change management process. If changes are allowed to be made without going through such a process – this is a huge red flag!
      2. Release Management – Vendors should have a complete release management cycle which includes development, testing, quality review, and scheduled deployment.  A lack of a reasonable prediction for when a release will be made available to us is a sign this process is non-existent or breaking down.  In addition, unpolished or substandard deliverables also (in part) point to inadequate release management processes.
      3. Software Development Methodology – When development is involved, the vendor must follow a repeatable methodology of some sort which includes requirements analysis, design, development, testing, QA, and deployment which may be “iterative”.  This is similar to, but not the same as a Project Management Methodlogy (PMM).  They must manage their own development effort.  They should have a Project Manager, Architect (for larger projects), Development Manager (or Team Lead), QA Manager (for larger projects), Test Engineer, and one or more Developers.  When we see single-resource programming this is a red flag unless the work is very small.
      4. Quality Assurance/Testing – A vendor should never release a product to a customer that has not undergone QA testing.  The goal of this testing is to ensure a quality product that meets business requirements.  If they don’t build QA/Testing into the project schedule, they don’t have a QA Manager or Test Engineer, etc then these are red flags – unless the development work is very small.
      5. Peer Review – Similar to QA/Testing, the vendor should peer review their work.  This is where they have peers of the development team that are typically not directly involved, review the code itself for compliance with development standards and best practices.  This is not testing against business requirements but usually results in a more quality result.  You’re not always going to see this, so it’s not a huge red flag when you don’t, but it sure is nice when you do!
      6. IT Governance – Sometimes vendors lack strategic IT governance which forces them to overschedule their resources.  When a vendor spends much of their time securing other business to keep their cash flowing, this is a red flag if they are telling you they are resource constrained.
Whew! I know this is a lot of info and it is nowhere near inclusive.  The bottom line is look out for these things and be ready to come up with a plan when you need to!  It is never helpful when the vendor is on the defensive.  Always reassure them we are here to help them be successful since their success is our success!  Don’t forget your project team and business customer in this regard.  If you have and profess this attitude, so will they!

Server SSL Certificate