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.

In 2007, while working for a vendor in banking operations – lockbox processing to be specific – we went through a merger with one of our stiffest competitors.  It was one of the most challenging processes I have ever encountered, as most mergers are.  Our company had been growing, our leaders were young and dynamic and our employees and customer base were family like.  We built our foundation on providing superior service with a superior product and boy was it evolving.  Then came the merger……….

The company I worked for several years and counting was setting the bar, as far as I knew, when it came to implementations and integrations of lockbox processing systems.  No task was too big, no conversion was too tricky…we had all the right pieces in place and all the right processes.  It was a well oiled machine that ran off of friendly service, easy to understand pricing models and dynamic project processes.  I have still to this day worked for a company that so smoothly adapted to change during a project life cycle.  Everyone knew there role, everone knew who to go to get things done. 

Growing up in Nebraska, I likened our successes to the Tom Osborne era of Husker football.  Leadership that had been in place for a very long time, turnover was nearly non-existent and everyone just knew how to do “it”….whatever “it” was. (if you aren’t familiar – Tom Osborne is known for having a staff and processes in place on his football teams that have hundreds of years combined experience together.  Few members of his staff left his side during his 25 years as football coach of NU)

After the buyout, things changed drastically.  Naturally, there was no need for 2 presidents, 2 vps of sales, 2 vps of service, etc, etc – so there was some fat trimming done there.  This signaled to many that it may not be a merger at all – but rather – a buyout of our customer base, our distribution channel and folks were on the move.

Our new leadership was quick to come in and not only ignore our current processes, but also begin implementing procedures we had never had to follow before.  We had a fixed pricing model for service, the new model was time and materials.  We had no PMO with no “formal” processes or documentation, the new model had a PMO and countless processes and documentation requirements.  We had an ability to change very quickly the scope of a project, the new model was turtle slow and allowed for little or no flexibility……or at least so it seemed.

Turnover was rampant as folks were leaving left and right out of frustration for the lack of understanding where we came from by the new company.  Many felt that feelings and ideas were completely ignored and there was a general sense of forced upon change with no ability to provide input.

In the end, there were two different vice presidents from the new company that came in and tried to steer the ship….but to no avail.  The turnover was too great and the customer base that came with our company was furious at the changes too.  How is it we all of a sudden bid our services costs at one price, only to turn around and bill MUCH more than that?  Well – because we went from a fixed pricing model to time and materials and no one…and I mean NO ONE….had a (enter word here) clue how to estimate time and materials.  On top of it all, we moved much slower and were beginning to provide poor service. 

The purchasing company decided to make a risky, yet very strategic move and brought back a valuable resource from the original company.  The previous vice president of service came back to help out, lead the entire group of people that were part of the original company and was made an executive committee member of the new larger company.  This instilled confidence, trust and most of all a sense of ownership back to the employees.  A familiar face to get us back together.  In addition, proper training was provided for all the new processes (and old ones that came back and/or stayed) and everyone had a say….or at least was led to believe so.

All in all there some huge lessons learned and the old model and new model could actually work in harmony and make things better than they ever were.  A hybrid of the two companies processes was about to happen and it began to pay off big time.  Better documentation provided better clarity to “what” was being done, which in turn provided a better ability to bid out services, which in turn provided an ability to service the customer better, which in turn made customers more happy….OK – you get the picture.  In addition, if there were changes in scope, we could now charge for those whereas before, we had no proof that the scope had changed.  It was very clear what was bid, when it was going to be done and how long it would take.  Any variation of this agreement would require change documentation, in favor of either side (the customer or the company). 

With the fixed pricing model and minimal documentation – we were at the mercy of our customers.  Our customers were like family….they were very close to us and we got along great….but just like some family members we have – they would take advantage.

I guess the real point of this entry points back to the title “Processes can evolve!” (notice the exclamation point!).

If both companies come in with open minds, move carefully, yet swiftly and avoid the “forcing” of policies and procedures without due diligence….there is a high probablity of success, especially if both companies were successful individually (which was the case here).  It’s a matter of playing to everyone’s strengths and taking the best of all worlds into consideration.   I think both companies in this situation had fault to claim and I imagine that is the case with most mergers.  If leadership can omit the paranoia from the general population of the company (easier said than done) and get folks to realize that most are not out to be malicious – but rather to do good, sound business – there can be great benefits in a merger similar to this.  Doors can open for employees from both companies, new things can be learned and ultimately the experience will pay off big time in a persons career…….