There’s an all hands meeting scheduled 1 month before the originally planned “Go – Live” date. The project manager looks like he hasn’t slept for 3 days. The project sponsor, who normally just calls in and is singing praises about the BPM initiative, now looks far more subdued when she is sitting in the room. All the developers and IT support staff are in the room. All the business subject matter experts are there. The test team is there too, though they haven’t really done much up to this point because what they’ve touched has barely been testable. The usual pre-meeting chatter isn’t anywhere to be found. That’s because everyone has been in one of these meetings before: the one where you realize all too late that you won’t make your date. Let’s go back to the project manager though…
Isn’t it the Project Manager’s job to make sure these “surprises” don’t happen? That’s certainly why the project sponsor wanted a project manager with agile experience in charge of the new BPM initiative. Everyone told her that BPM is best delivered when following an agile methodology, so to reduce the risk of this exact meeting ever happening the project sponsor made sure the PM role was filled appropriately.
“It’s the top of the hour, so let’s get started,” says the Project Manager. “We don’t want to spend too much time rehashing how we got here, but it’s important to address the drivers behind why we are late, so we can provide an updated go live date. So… what happened?”
If you’ve been in one of these meetings before, you know how painful they can be. Normally, part of that pain is that the proposed root causes of the delay had been brought up well before this meeting. Or it might be that you were actually following an agile methodology complete with user stories, iterations, and playbacks to end users yet things still went sideways. I would venture to bet that at least one of the tips below are relevant to your situation.
If you haven’t been in one of these meetings, lucky you! Enjoy reading the following tips so that you can hopefully never find yourself in this type of meeting for a BPM project.
In no particular order, here are the top 5 most common BPM project delivery problems along with some solutions about how to avoid them all together:
Problem 1 - Infrastructure issues slow down or halt the project
Too frequently teams underestimate the effort and complexity to stand up on premise IBM BPM platforms. While I must admit the product has improved tremendously in this area the past 2 years, we’re still talking about an enterprise capable system that can be configured a variety of ways depending upon your needs and existing architecture. Even if you have read the IBM BPM Security Redbook, I would encourage you to use expert services to do your first installs and get started on those installs at least a week before any developer needs to start work. Better yet, seriously consider a shift to the cloud with IBM BPM on the Cloud. The Salient BPM team can also help you better understand your options between On-Premise and IBM BPM on the Cloud.
Practical Solutions: Treat your development environment (ie the IBM BPM Process Center) as if it is a "Production Environment" from an uptime perspective. Have it ready at the beginning of your project. Keep in well maintained and up to date on fix packs. Better yet move to the cloud with IBM BPM on the Cloud.
Problem 2 - Testing teams are engaged too late and/or BPM users don’t truly get “hands on” until UAT
For most companies that have dedicated testing teams, even if your business users have done a fantastic job at documenting user stories, they won’t suffice as requirements documents you can just hand off to traditional testing teams. It’s important not to ignore this reality or think it will just sort itself out at the end of a BPM project. Instead there are two options that seem to work:
- Include your BPM Testing team under the umbrella of teams “shifting to agile”, just like your business users and developers are having to do
- Measure how much time your business users and testing team has to spend creating those supplemental “requirements documents"
#1 is preferred and doesn’t mean the testing teams across the whole enterprise need to change, just the team on the first project. Having them engaged early on during user story creation makes a huge difference in their perspective on how to test and create test cases.
#2 is more of an approach to show how costly it can be to not do #1. You are essentially “biting the bullet” but will be prepared to show that in today’s ever changing business environment you can’t keep doing “business as usual.”
From an end user perspective, most every team responds positively to having Playbacks at the end of iterations because they get to see what has been worked on early and often. However, you fall short of the real value of iterative development if you don’t actually get the solution into the hands of those end users after the Playback. The Salient BPM Methodology advocates for this by always deploying the Playback snapshot to a separate environment than Development, so business users and testers can get hands on the application.
Practical Solution: Deploy a working snapshot after each iteration that doesn't require a ton of overhead by end-users to get "hands on". In some cases, that experience is a more powerful force than the Playback.
Problem 3 - A huge chunk of time during iterations is dedicated to planning future iterations
Does it always feel like pulling teeth when you ask your developers to provide estimates for user stories or to task out their user stories into management chunks of work? Does your business team always feel like they are in meetings planning for the next iteration?
This is a major complaint that comes from teams who are just starting agile. In my experience, this is more of a symptom of lack of discipline or familiarity with the healthy routines of agile development. Yes, agile development is far more collaborative than waterfall, but that doesn’t mean everything has to be done in a group setting. Creation of user stories and adding/estimates development tasks should ultimately be done offline. User story point estimation accuracy is normally more tied to experience and prior velocity rather than rigorous analysis of the details of the user story. Planning meetings should start with a set of well written and estimated user stories, so that the agenda is really just plucking out of a backlog and prioritizing.
Practical Solutions: Enable end users to create high quality user stories on their own. Have them using the PLM tool directly with no proxies. Don't be too concerned with accuracy of estimates in early iterations, focus that energy instead on staying disciplined as the project progresses so your velocity becomes clearer overtime.
Problem 4 - Not properly engaging your UX team
It’s becoming more and more common place that UX teams are embedded in solution delivery teams… and for good reason! Having a well-designed solution, particularly for UI elements, is expected by end users now more than ever. This becomes even more critical when mobile compatible solutions are needed. . There might even be a corporate mandate to get screens approved for all new releases.
In the not so distance past, UI or UX conversations were put on the back burner for BPM projects in favor of process conversations. While it’s important to keep your BPM projects focused on measuring process improvement, times have changed and you need to make sure your BPM team can deliver a well-designed user experience and not just a process application.
Practical Solution- Don't discount the importance of good UX. The days of UX being a sacrificed at the start of projects in the name of expediting your first project are over. UX shouldn’t drive the BPM project, but UX is a passenger than can’t be left behind when starting your BPM journey. Make your UX development easier with Salient’s SPARK UI Toolkit.
Problem 5 - The delivery team is pleased with the functionality at “code freeze”, but the executive sponsors are underwhelmed and wanted more.
Executives expect their investment to realize certain benefits, so the production solution must be valuable in the eyes of executives as well. The value might change overtime (hopefully it increases), but it should never come as a surprise to executives. Managing that expectation is critical because BPM project typically come with lots of change (new platform, shift towards agile from waterfall, business user driven, new automation, etc.).
Practical Solutions- Don't let your developers, testers, business analysts, and end users lose sight of why your project was funded. If the solution starts to take a different form than was originally envisioned, it’s everyone’s responsibility to make sure the solution remains aligned with the project’s goals. Project Manager’s also need to make sure these shifts are well understood by executives and that the message is being received… not just embedded in the middle of a weekly status update. This is why the Process Owner role and a North Star Analysis are key parts of the Salient BPM Methodology. (READ: How Our North Star Methodology Enables Successful Digital Transformation)