The last few months have been really fun for me. I've had a couple of really successful BPM implementation engagements and seem to be on a roll. I would love to take credit for the success of these clients, but the reality is that the makeup of their implementation teams is what really made the difference...
What makes a great BPM Implementation Team? Of course it's the character of the people on the team - but it's also the "perspectives" of those people that really makes the difference.
In the bad old days of software development, one group would write requirements and another group would implement those requirements. Let's call the first group "Business" and the second group "IT".
There never really was a 'Business/IT Team" that was tasked with building the solution... it was a Customer/Supplier relationship.
Rapid Iteration BPM implementation projects, like the ones that I work on, depend on "Business" to take on building responsibilities and "IT" to take on requirement writing responsibilities. We don't structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:
The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.
In some ways the relationship between these two folks resembles Agile's Pair Programming. That's the practice of sitting two developers down side-by-side at a single workstation. While one developer types in code, the other developer reviews the code to catch errors and insure compliance with the requirements... take that concept up to the level of Business Relevancy and you have one person who is concentrating on getting the technical aspects of the solution built and another who is concentrating on getting the business aspects of the solution built.
While we're touching on the topic of Agile programming, I want to hasten to say that many of the concepts of Agile are applicable to a BPM project, but there are some very key differences in the priorities that you assign to the implementation of features and functions.
In BPM, the Process is the Story. The User Stories for individual process activities, although interesting, are just chapters in the book. You must give priority to implementing all of the chapters to some minimal level of functionality before working on any other aspects of the solution. The process-wide dependencies (activities, flow, payload) must be the focus of your initial Sprints, or you are quite likely running in the wrong direction.
But I digress... back to the core of our dream team...
The Business Lead is responsible for getting all of the required business functionality of the process implemented. It should also be noted that the Business Lead owns the interpretation of the business requirements. Any ambiguity in the business requirements must be clarified by the Business Lead. Any changes to the business requirements must go through the Business Lead. The Business Lead is the fountainhead of all things business (as far as the team is concerned).
The Business Lead is the primary interface between the implementation team and a host of business folks. The business cast includes the following:
The Technical Lead is responsible for getting all of the required technical functionality of the process implemented. As with the Business Lead, the Technical Lead owns these aspects of the process, but very likely there are many specialists involved to do the actual implementation. What you are looking for is someone who has very good rapport with the Business Lead and the technical background to spot all of the technical implications of the process that must be addressed. As I have blogged before, BPM solutions don't usually require a lot of Software Engineering, so the breadth of the Technical Lead's knowledge is usually much more important than the depth of the Technical Lead's knowledge... You need someone who knows which experts are necessary and when to engage them.
The Technical Lead will be supported by a host of developers, and often these folks are specialists. You'll often find the following cast:
Note that the involvement of the team members varies in intensity over the life of the implementation project. The Business and Technical Leads are always "on call", but the lion's share of the Business Lead's efforts are early in the project, and the lion's share of the Technical Lead's efforts are in "the middle" of the project. When you get to User Acceptance Testing the efforts of the Leads seem to be evenly split. All of the other team members can come and go as needed... continuity is provided by the Leads, so the supporting cast members can be utilized effectively on multiple projects if need be.
If you organize your team around a Business Lead and a Technical Lead as I've described, then I'm willing to bet that your project will run smoother and you'll reach your goal sooner - and I'm also willing to bet that you'll enjoy getting there.
What makes a great BPM Implementation Team? Of course it's the character of the people on the team - but it's also the "perspectives" of those people that really makes the difference.
In the bad old days of software development, one group would write requirements and another group would implement those requirements. Let's call the first group "Business" and the second group "IT".
There never really was a 'Business/IT Team" that was tasked with building the solution... it was a Customer/Supplier relationship.
Rapid Iteration BPM implementation projects, like the ones that I work on, depend on "Business" to take on building responsibilities and "IT" to take on requirement writing responsibilities. We don't structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:
- All Business requirements have Technical implications
- All Technical implementations have Business implications
The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.
In some ways the relationship between these two folks resembles Agile's Pair Programming. That's the practice of sitting two developers down side-by-side at a single workstation. While one developer types in code, the other developer reviews the code to catch errors and insure compliance with the requirements... take that concept up to the level of Business Relevancy and you have one person who is concentrating on getting the technical aspects of the solution built and another who is concentrating on getting the business aspects of the solution built.
While we're touching on the topic of Agile programming, I want to hasten to say that many of the concepts of Agile are applicable to a BPM project, but there are some very key differences in the priorities that you assign to the implementation of features and functions.
In BPM, the Process is the Story. The User Stories for individual process activities, although interesting, are just chapters in the book. You must give priority to implementing all of the chapters to some minimal level of functionality before working on any other aspects of the solution. The process-wide dependencies (activities, flow, payload) must be the focus of your initial Sprints, or you are quite likely running in the wrong direction.
But I digress... back to the core of our dream team...
The Business Lead is responsible for getting all of the required business functionality of the process implemented. It should also be noted that the Business Lead owns the interpretation of the business requirements. Any ambiguity in the business requirements must be clarified by the Business Lead. Any changes to the business requirements must go through the Business Lead. The Business Lead is the fountainhead of all things business (as far as the team is concerned).
The Business Lead is the primary interface between the implementation team and a host of business folks. The business cast includes the following:
- Process Owners - usually the Operations folks who are responsible for keeping the business running smoothly
- Business Subject Matter Experts - the folks who really know the details about specific aspects of the business
- Process Participants - the folks who are going to use the solution that you're building
The Technical Lead is responsible for getting all of the required technical functionality of the process implemented. As with the Business Lead, the Technical Lead owns these aspects of the process, but very likely there are many specialists involved to do the actual implementation. What you are looking for is someone who has very good rapport with the Business Lead and the technical background to spot all of the technical implications of the process that must be addressed. As I have blogged before, BPM solutions don't usually require a lot of Software Engineering, so the breadth of the Technical Lead's knowledge is usually much more important than the depth of the Technical Lead's knowledge... You need someone who knows which experts are necessary and when to engage them.
The Technical Lead will be supported by a host of developers, and often these folks are specialists. You'll often find the following cast:
- Process Flow and Data Developer - someone who really groks how to implement the process and data requirements with your BPM suite.
- Human Interface Developer - someone who is a wizard at building all the Human Interfaces to your process.
- Integration Expert - someone very skilled in utilizing external systems... Mostly SQL and Web Service skills
- External System Expert - you'll need one per system that you need to interface with
So here's a diagram of your extended dream team:
Note that the involvement of the team members varies in intensity over the life of the implementation project. The Business and Technical Leads are always "on call", but the lion's share of the Business Lead's efforts are early in the project, and the lion's share of the Technical Lead's efforts are in "the middle" of the project. When you get to User Acceptance Testing the efforts of the Leads seem to be evenly split. All of the other team members can come and go as needed... continuity is provided by the Leads, so the supporting cast members can be utilized effectively on multiple projects if need be.
No comments:
Post a Comment