Managing Implementation Projects – Tips and Tricks

Is there a difference in managing a project that is implementing a “Commercial-Off-the-Shelf” (COTS) application, versus managing a new software development project? Many of you would say there is a world of difference. In my opinion, it is not that simple – there are some project elements that are common to both, and some things that are much different.  Here are some best practices from my 20+ years of managing successful projects that I’d like to share with you today.

Software is Software
Technology projects involve that dreaded word “software.” But let’s not panic. First, software has become ubiquitous—with few exceptions, is probably inside of every physical item we buy or use today (cars, TVs, cell phones, etc).  Granted, not all software is the same. Some can be configured, while other software is “locked down.” When organizations
decide to build custom software applications rather than buying a COTS tool it is often because they need to lock down functionality to a specific use or process or because they need some special function that COTS software does not have.  More and more often, organizations are discovering that a COTS application will do 80% of what they need, with 30% of the cost.

Consequently, I have been managing a lot of Microsoft® Project and SharePoint® implementations this year. These software products are very powerful and can be highly tailored to an organization’s business processes without writing new software.  Projects to implement and configure tools such as these tend to ignore some of traditional software lifecycle aspects and I don’t think this is a good thing. Here are some of the steps I think still need to be included when planning and managing an implementation project for a COTS application.

  1. Requirements.  It is the key to successful projects—COTS or not.  Managing a project still requires knowing what the client and user requires and really needs (vs. wants) to produce their job outcomes.  (Listening to Customers)
  2. Planning.  I don’t think I have to elaborate for my tradition PM readers – this is the only way to identify and set expectations, schedule, staff and resources.
  3. Design.  Even though the application may be COTS, I find that the choices for configurations, the level of customization, and the ability of the latest generation of tools
    to change the look and feel of the product – really does require a good design.  Hopefully the design is done by professionals who are experienced in the software and have implemented it before. (Design with Users in mind)
  4. Testing.  I would hope that any project involving software would include this element, but have been amazed at how many times I see something put into production without testing because it is a COTS solution. Be sure your users get a chance to test the new application (UAT). (For more on testing see the post on usability testing.)
  5. Documentation. I can’t say enough about this – and I am NOT talking about the manufacturer’s manuals. Documentation does not have to be volumes of paper. However, there should be something for the support staff that documents the configurations and changes that were made to the system. I find that when outside consultants are used, this activity is more likely to be done. In my experience, when internal staff perform the configurations, documentation to more likely to be “lacking.”
  6. Training. My #1 pet peeve is that too many organizations are now “short changing” training to cut costs. They expect that all their users need is a simple, short one-hour overview and they will become experts in using the system. I fight to include a more robust and comprehensive training as a part of the projects I manage – and yes, I know that this increases the cost of the project.  But in the long run, training that equips people to use these new tools to do their jobs also increases the likelihood of system acceptance and long-term success!  (Making training better and How not to do training)

People are People
Back in 2009, I wrote a post titled “Does anyone listen to the Customer?” which was about how the PM should be the client advocate.  In practice, a project
manager uses customer requirements, resource knowledge and experience to construct a realistic project schedule and budget.  But a good PM knows that on a COTS implementation, the customer does not really know the full limitations or capabilities of the product.

I am currently managing a project where the Business Unit clients were being asked to tell what they needed the system to do.  This was without first giving them either an
expert to guide their input, or showing them what the application could potentially do.  These are people who know their business really well – but do not have a concept of what the new application might do.

Now I believe in focusing on solving business problems for a successful project, but the process for building good requirements should not lie completely with a novice business user.  We will either get requirements that cannot be accommodated or miss opportunities to really leverage the new tool because “they didn’t ask for that function or
capability”. If the user knew all of there was to know about the tool, he or she would probably not be in the business unit but rather in IT.

At the end of the project we want the implementation to actually solve or improve some real business process issues. The best way to insure that is to involve the people who have to use the technology and see what intersections can be made between the application’s functions and the user’s job outcomes.

So how many of your projects are actually “implementation projects” rather than software development ones?
Leave us a comment….

User Acceptance Testing – Dealing with Clever Users

I have never been particularly fond of the ubiquitous phrase, “where the rubber meets the road.” However, if ever there were a situation when that phrase applies, it is user acceptance testing (UAT). After all the planning, designing, meetings, reviews and internal testing, there is one final act before the buyer (or internal client) accepts the software or solution. Yes, your team and you have worked months to perfect it but the real gate for saying it is ready is when it is tested by real users on their system.

Bad User Acceptance Testing Strategies
Waiting until the end of development to think about user testing: NO-Start early. Plan the user testing from the beginning of the project. Build user testing into the schedule. Do NOT fall victim to the strategy of, “we’ll rely on the results of system testing and skip user testing to catch up with a delayed schedule.”  Those of us with lots of years experience can tell you that you build in testing and most surely with actual users if you want the system to work in the production environment.

Not allowing plenty of time for user testing: In a report from Sentry, they found that (and I paraphrase from their report: “assume that you have 120 test items such as producing a specific report or scanning 10 batches of 30 documents each into a database or generating an export file of 600,000 records. Further, assume it takes about 3 hours to setup each test cycle. Do the math. The time to setup, test, collect data and analyze approximates 360 hours.)  So how many projects build that into their schedule?  The ones that do I will bet find lots of real world issues and work them out before deployment.

Your project’s testing requirements will differ from any other projects because your product and situation are unique. However, the point is that meaningful and useful user testing takes time and planning.  You might even do something novel like include users up front in planning what testing and acceptance criteria they will use!

Here’s another failing user testing strategy from our friend, Dilbert.

OK- so enough bad strategies, how about a few tips on what to do right:

Good Advice on User Acceptance Testing:

  1. Include user-testing requirements in the original proposal, plan, cost and schedule. Use input from your business analyst or project team – that include customer representatives – to generate typical scenarios and scripts for user testing.
  2. Create a detailed plan of what the UAT is testing. You do not want a bug report that says, “The system failed to turn straw into gold.” User testing should be done based on agreed requirements, not everything a user may want the system to do.  In other words, bound the scope of the testing to be in line with the solution.
  3. Select test subjects (let’s call them users) with a range of experience and diversity of backgrounds following pre-defined scripts to get from task beginning to task complete.  Do not pick all junior or all experienced users, a mix is the best.
  4. Train your users (test subjects) how to report problems. “User Acceptance Testing War Stories – Writing a Perfect Bug” suggests that testers write down the steps they followed that led to failure. Then wait a few hours and try to follow the steps as they wrote them to see if the bug appears again. You are teaching testers how to find bugs and report them with sufficient detail to developers to repair.  Use some online tool if possible – it makes it easier.  Even a SharePoint list can be used to track the items that come out of the UAT.
  5. Maintain detailed reports of testing including procedures and outcomes. Communicate findings with the team, management and clients. Depending on the timing of the UAT, you may want to submit status reports daily or weekly. Besides a cursory pass/fail, add some analytical information about causes or commonalities.

Remember that user testing is about making sure the system does what the customer claimed was needed to help them do their job. If the specifications and earlier plans, all agreed to by the parties involved, resulted in a product that does not support user’s needs, document the revised needs and begin the process of negotiating the follow on contract.

Best Practices and Lessons Learned:
This is one of my favorite topics and I have made almost every mistake from cutting out user testing to letting users test things not included in the original scope and requirements.  A couple of Lessons learned that I hope you can avoid:

  1. Get the client/stakeholders involved at the beginning to define what the testing will need to be.  It is like having the students help write the test – they can’t say it was a bad test.
  2. Balance the formality of the UAT with the scope and length of the project and solution.  I have seen too much formality for a small system acceptance and not enough rigor for a large scale solution being deployed for thousands of users.
  3. Don’t start out user testing or UAT with negative points – in other words don’t sound like a lawyer!  If you have done everything right, including getting the users to help up front, then this is an exciting time where they get to try out the system before everyone else.  Kind of like test driving the new model car before everyone else.

So what are your tips or experiences in UAT?  I am sure others would love to hve you share.

Thanks for sharing.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site