I’ve been reflecting quite a bit lately on how to help improve the inner workings between client and vendor in the IT arena.  I will add my thoughts and discovery as it comes in, but for now I have enough for a good start.

Since recently stepping in as a consultant / sr. program manager resource for a large client with a vendor, I noticed an amazing amount of “noise” causing large quantities of chaos when teeing up and executing projects.  There are multiple resources on both sides that are responsible for seeing through specific projects.  Email traffic, phone calls, issue logging and action item tracking has been all over the board and it had gotten to a point where it was a daily challenge to circle the wagons to make sure everyone was up to speed on the statuses of each initiative.

The one very alarming concern with this is that many of these projects are dependent on each other in one way or another…be it a code dependency, an operational impact, business priority, etc, etc.

We’ve decided that the best way to solve this problem is to have a static resource at both the client and vendor ends responsible for keeping a pulse on the broader picture, knowing enough details to make sound decisions and ultimately dictate priority….or at least recommend the best path to follow and let the business dictate priority based on the information known.

Doing this will hopefully lead to greater efficiency and success for all initiatives, leading to more revenue at a lower cost.  It will also give back to those being pulled in to all directions the time to stay focused on the tasks they need to, to bring their respective projects to closure.

I will continue to post updates on the success of this – but I feel very confident that this one step alone will solve many problems that have come up in recent years between this client and vendor.

I recently visited a client to discuss many topics surrounding their software testing and deployment project process.  Though there were many outputs from these meetings, there was a very obvious bottleneck in their QA area of the processes.  Due to this we spent a good deal of time on this and I felt it would be worth sharing.

This client is a client of a particular software vendor, so they aren’t the developing party.  Please keep this in mind.  What this essentially means, is that much of the “unit” type testing surrounding Alpha or Beta releases (or even final releases) should be unnecessary, however this particular client is finding itself peforming much of the unit testing that it should have the confidence with being completed by the vendor.

Here is some info passed onto them:

When testing major software upgrades, the test approach should focus on business flow and not on application unit testing (except for client custom-developed code).  The basic approach (in this order of execution) to testing is as follows:

1. End to End Testing: Approx: 5% total testing effort
2. New Feature Testing: Approx 30% – 40% total testing effort
3. Regressions/Baseline Testing: Approx 60 – 70% total testing effort

The testing effort kicks off with end-to-end testing, which puts items completely through the standard business workflow.  It is designed to identify basic problems quickly and without requiring several iterations to get a first pass through the entire workflow.  It is not intended to test specific test conditions such as exception processing, etc.

Once the end-to-end test is complete, the QA team will drill down on specific new functional areas for detailed testing.  There may be one or more test cycles associated with a given functional area, and the QA team may test new functionality testing in parallel with regression tesing, if it makes most sense.  The regression test, however, cannot be considered complete (or in some cases started) until the new functionality testing is complete.  The QA team will identify each of the functional areas to be tested and the associated testing at the outset of the test in the form of a test plan – they will strive to bring closure to each functionality area as soon as possible and provide regular progress reports to the appropriate team members.

Each new release brings additional functionality, and new test cycles will need to be developed to validate that new functionality, particularly as it is applied to the clients operating environment.

One thing I’ve seen often is a lack of clear milestone standardization and understanding.  It’s crucial to all those involved who are part of any project within an organization or who receive updates regarding these projects to know what each milestone may mean. There are many “basic” statuses or milestones for every project within an organization and/or between its vendors.

Examples are:  Request, Discovery, Requirement, Design, Development, Testing, Staging, Production, Support and Closure.

The naming of these milestones is far less important than having a consistent milestone process that allows for clear understanding of where a project may stand.  This helps in all aspects of a project’s success. Project Management Offices or the equivalent should define and document these milestones to be used as a guide for project status, health and monitoring and distribute to all that need to know them.

 These pre-defined milestones should be used as a guideline for all projects and any deviation from these should be encouraged only when it makes most sense for the success of a particular project.  Consistency in this process will allow for more clear communication to all affected parties.

One cannot place enough emphasis on the value of setting proper roles and expectations for ANY project and the importance becomes even more glarring when there are multiple business units, vendors and mini-projects all trying to get to the same goal.

Here are a few quick must dos at project kickoff regarding this topic.  There are many others – but these 5 things should be at the top of your list when kicking off a project – and MAKE SURE you invite all known project participants to the kickoff meeting!!!

1. Clearly define and document all team member roles.  Don’t just break it down by groups, but be very clear and concise toward each individuals specific role.
2. Clearly define and document any and all owners of the various aspects of the project.  For instance, if there is a business decision conflict that comes about, who makes this decision?  The more you can dwindle this down toward one person, the better.  Decision by committee is very challenging (though sometimes it cannot be avoided), so t should be avoided if at all possible.
3. Cleary define and document the communication plan.  Who gets what when in the form of communication has to be agreed upon and the plan should be distributed to all team members by the project manager(s).
4. Define who will resolve resource conflicts by dictating priority.  Is this the PM?  Is it a business manager?  Does there need to be a meeting if one comes up?  There will be plenty of priority conflicts – they all need to be quickly resolved and having a sound game plan ready to execute when needed.
5. Clearly define and document the status update process.  Is it via email or meeting?  What is the frequency?  Who participates?   Is there a standard agenda?  These are all things you should think about.

Knowing the answers to these questions and having sound documentation distributed out to the project team will save plenty of heartache down the road.

Happy kickoff!

Matt