This article is a difficult one to write. We all have one, I imagine. That one project that you wish had never come your way. Maybe everything went bad from the start. Maybe everything went well and ended horribly, leaving you miserable and wondering why and how it all went wrong. Or maybe you were overloaded and another project added to your plate at that moment was just too much at once. Whatever the reason, I’m guessing at least most of us have the one we wish we could have back – or possibly never had at all. I know I do.
It all started harmlessly in September 2007 at a major pharmaceutical manufacturing company. This was to be a $700,000 software implementation with three major phases implemented over nearly a year-long project.
Project Kickoff
The Project Kickoff started off well, but the customer was horrible over-represented. There was a fluctuating attendance on the customer side ranging from 15 to about 25 attendees depending on the discussion topic at the time. Our delivery team was represented by 4 individuals – the PM (me), a Business Analyst, the PMO Director, and a company VP. In this case, the Project Kickoff also doubled as an Exploration session and lasted several days, so it was appropriate at times to have several customer-side attendees, but 25 is way too many. As you can probably guess, there were too many side discussions, inappropriate design-type questions for that stage of the engagement, and revolving door attendees that meant the BA and I often had to cover material again for those who missed it the first time.
Design Meetings
As chaotic as the Project Kickoff/Exploration combined sessions were, the Design meetings were so much worse. I’ve never had a Business Analyst – or any team member for that matter – break down in tears outside of and then during a customer meeting before. This one goes back to the ‘lack of PM involvement in the sales process’ though. Every 30 minutes something was discussed that would be in direct contrast to what Sales had set as the customer’s expectations. Emails, text messages, and break-time phone calls to the main Account Manager were a constant activity during the Design session. It seemed like we were constantly behind the 8-ball with the customer and were trying to find out exactly what they had been told during the sales process.
The biggest struggle I had as the PM was maintaining control of the meetings. It caught me off guard when the BA completely lost it and it was a downward spiral for a while after that. Keeping the customer-focused not on their frustrations and their ‘requirements-definition-thinking-on-their-feet’ but on what the Statement of Work (SOW) stated and how we were going to design the system for them became my Number 1 priority.
And Beyond
I wish I could say that it all turned around and worked out beautifully, but I can’t. I can say that it did get better and that’s basically due to that last statement above. The BA and I regrouped, and worked very hard to keep the customer focused on what we were tasked to do.
They had issues – that much was obvious. They had not obtained the product training that they should have had prior to the engagement. For this type of software implementation, it is basically a requirement, but Sales glossed over that and left the delivery team to take that hit.
The customer had also not pre-defined their business processes very well and therefore really did not have a good handle on their requirements. Keeping them focused on the SOW and letting them know that ‘gaps’ will be identified, documented and worked into the system during the implementation and in a later phase, if necessary, brought them back on track for the Design session and beyond.
However, since it was an East Coast client and I am near the West Coast, eventually I moved on to a new engagement and handed off to an East Coast PM. I like to see projects through, but I was ok with handing this one off.
The Issues and What I Would Do Differently
Customer team too large
Had I known the customer was intending to have that large of participation I would have done one of two things.
- Discussed upfront with the project sponsor their intended attendance and worked with him/her to limit the number of attendees to key SMEs only. That way the meeting can stay on a better track with much less distraction and side issue discussions.
- The other alternative – if it would have even helped – would have been to go back to the overall methodology and break the Project Kickoff and Exploration into two completely separate phases with separate meetings and likely some different attendees. By combining them – at least with this engagement – we seemed to double our representation as the customer wanted to ensure that every base was covered.
Customer expectations
The Sales to Project Delivery Team handoff was weak. Part of that was my fault on this one as I had just finished kicking off another project in Chicago the week before. This project was handed to me as a surprise and I had very little time to get up to speed or get detailed info from Sales. But, I also didn’t have the opportunity to say ‘no’ to the assignment so there wasn’t much else I could do. The customer didn’t understand that training was needed on their side. They also weren’t fully ready with their business processes and requirements. In reality, the Project Kickoff should have been delayed at least 30 days to allow for some training and for the customer SMEs to sit down again and come up with process definitions and requirements that would be revised after the training. This would have made the Exploration and especially the Design sessions run much more smoothly.
Feedback
If you have feedback on this article or wish to share some of your own less than desirable experiences, please feel free to comment. I look forward to the responses.