Posts tagged: project processes

Must haves for any IT Software Service Provider

I spent a couple years with a company that made some unbelievable strides in the time I was there.  When I first started, there were so many gaps in their processes that caused unneeded stress, unbelievable work hours, the highest customer dis-satisfaction I have ever witnessed and tension between team members.  I thought it would be interesting to post a paper I wrote, shortly after starting with this company since it has so much relavence to any IT Software Service Provider.  I’m happy to say that through everyone’s dedication, the hiring of an additional leader and a willingness to service their customers – much (if not all) of this is in full scale motion – and working very well. 

Below is really a combination of an initial gap analysis for the company processes, detail on previous process experience and general documentation to help guide change in 5 key areas:  Requirements, Testing, Estimation, Accountability and Project Management.

Requirements:  Any long-term successful software project must have clearly defined, well thought out, group decided upon, pre-work requirements.  This is a long drawn out process that may require long, somewhat boring meetings with the requestor(s), the developer(s), the PM, the testers etc – but it is key to saving time (=money) and reducing (in some cases eliminating) problems after the fact.  The cost to re-do things increases exponentially, hence the 1:10:100 rule or the waterfall effect.  It can be painful to implement full scale requirements documentation processes, but in the long run it will be extremely beneficial for the overall health of the business unit and technical teams alike and also helps more accurately meet the users needs at first crack.  Not to mention anyone that already has certain expectations made up in their mind, will be given a forum to get it out on the table before it’s too late.

Notes about effects and alternatives along the way can help pave the path for when a similar circumstance is met.  This may require some additional tests (business tests) so we know the process is running smoothly.  Lessons learned meetings, water cooler talk, whatever, however it gets to the PM or another appropriate party to document the missteps for future reference is extremely handy.  The key is for requirements, all changes (hopefully through change control) and outcomes to be documented and learned from, good and bad, from both the business and technical units.  As long as there is something being done that never has been done, there are probably going to be problems with the requirements, but they can be minimized greatly using the right steps.

Testing:  Testing should be not only for items that have come through the queue in change, but also complete regression testing for those areas that are effected by the change….for instance, a change in automatic payments somewhere in the workflow could also effect any of the payment logic processes downstream OR it could effect something upstream that will eventually hit that same point in the logic path.  Good communication (going back to requirements) upfront with the development team, testing staff and the business unit can help us determine not only WHAT needs to be tested, but also get a really good feel for the testing effort – which needs to be included in the total project completion estimates.

Essentially, as part of the requirements gathering, or at least as a follow up, we should have documented estimates for not only the development effort (i.e. – 20 hours to do “x”) but also for the testing effort (typically testing effort is estimated at exactly half that of the development effort, for cushion).  This is obviously flexible, but starting here is something close to industry standard.

Estimation:  Again, it all ties back to the requirements piece, but out of gathering those requirements, the PM should be able to have a really good feel for the total effort, on all fronts.  At the very least, it is a good precursor to successful, on time and on budget software project work.  We can start our estimates with “educated-guess” effort and learn from those and adjust accordingly.  This is part of a painful process, because at first, it may take more time to get things done, out the door, etc……but with near imminent certainty in the long run, things will get done more quickly and at a lower cost in both dollars and resources.  Having a good feel for what the total effort is going to be, is a crucial part to the success of any project and really shouldn’t be ignored or skipped over.

Accountability:  Some form of tracking of the efforts, even if manual, would be helpful in gauging how we are doing as a group, how time is actually being spent (for future reference) and, not to mention, show the business’ worth – which is no doubt huge to the holding company…..but how fantastic would it be to have documented proof that we are offering a significant return on investment?  There are many systems out there for time tracking, effort tracking, etc….but they can get very costly.  It would be ideal to find a way to track the total effort, tally the numbers and have this as a reporting tool……this could be something the PM could track, or otherwise designated. 

Project Management:  Ultimately, this piece will take care of itself with simple proactive organization, action and re-action.  Needed are requirements outlined and accurate estimations to be able to set goals.  The project should always be something that is finite.  It needs to have a clear start and a clear finish…….which doesn’t necessarily mean there needs to be tons of extra documentation and extra “busy work” for anyone, but it does mean that everyone should be on board with the expectations as to when something starts and when it ends.  This could be a simple patch or change to the system or something HUGE that takes weeks/months.  There are going to be uncertainties, risks, delays, problems and issues that will all need some action and attention….that’s a given, though we’ll hope they are always very small and non-threatening…..but given that, we need to control the things we can for “best success”.

Merger: Processes can evolve!

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…….

Dansette