How is SIPOC (Supplier-Input-Process-Output-Customer) concept implemented in Jazz/ RTC?
Hi.
I am new to Jazz and RTC. So, please forgive me for the slightly lengthy, and maybe basic, nature of this note.
Firstly, let me state that I am very keen to use Jazz/RTC in a live project, having read and seen glowing tributes to its rich history, capabilities and successes.
For the past month or so, I have been struggling with a conceptual question regarding process flows, for which I am not able to find a clear answer in the documentation on RTC/Jazz, nor in the various documentation/videos in the public domain, nor from some "experts" that I have been interacting with during this time.
RTC is stated to enable disciplined software development process via automation. Further, it is stated that there are pre-built process templates (COTS, agile, etc) available and customizable as per the needs of a project.
A process flow to me is a sequence of SIPOCS, i.e. Some "supplier(s)" providing pre-defined "inputs" for processing by the "process step" which is performed by a "process role" which produces "outputs" to be delivered to "customer(s)" of the process step; the sequence repeating until the end-to-end flow is complete.
In the software domain, for example (assuming a traditional formal process method, which is what I am envisaging this tool for - in fact for a multi-COTS based implementation over 4-5 releases), this chain could be (I am simplifying things a bit....)
1. End user giving requirements
2. Business Analysts elaborating it and producing a formal set of signed off user requirements
3. Solution Architects developing high-level solutions and designs that map to the various systems/ sub-systems, including the interfaces etc.
4. Sub-system architects creating detailed low-level designs that correspond to their respective sections in the High-level design
5. Review and finalization of the development/configurations/customizations etc to implement the solution/design
6. Implementing these by various engineers across the system landscape
7. Release of the artifacts for Testing
8. Defects identification by test engineers vs the design
9. Fixing of the defects by developers
10. Releasing the defect-free artifacts into "live" environment
In a moderately large project, this pattern could be repeated across the various tracks/areas in the project, also across multiple iterations ("releases" or "builds" etc).
Question Set 1: Is this what is meant by a "Process Template"? With what fidelity can Jazz/RTC capture the SIPOC intent of the process flow? Is there a way to specify the expected inputs and outputs from each step, so that we can ensure that the process moves forward as intended? If so, how much of this is out-of-the-box behaviour? How is this implemented in Jazz/RTC? Do the "standard" processes templates (I was considering using the COTS method) capture SIPOCs associated with a method to this level of detail?
I would also imagine that at the planning phase, each activity in this flow, corresponding to each team/team member is enumerated by the project manager, and assigned to various team members who are available to play the corresponding role.
Now, lets say that the project moves from "planning" phase (say, for Release 1) to the "doing" phase for that release.
Question 2: How is this transition triggered by the Project manager?
IF the SIPOC is capturable by Jazz/RTC with high fidelity, my EXPECTATION would be that the automation will orchestrate the process intent, i.e. The first person in the chain will get a task in their "Todo", and they will work on it, and they can only move it forward once they produce the necessary outputs.
Further, once the process step completes, the next person or persons(s) corresponding to the next process step will automatically (since the process intent is known to Jazz/RTC) get a task in their "Todo". Till the previous step is finished, they may see their tasks as "planned", but they obviously cannot start working on it, since the previous step is not complete. So, Jazz should not trigger a "Todo" until it is their turn to step to the plate.
Question set 3: Is this the behaviour of Jazz/RTC? Are the tasks associated with the plans "triggered" in this way for each person, as the process flow moves forward i.e. do the users see tasks that require their attention in their dashboard when it is their turn to act - with links to the artifacts that they need as inputs?
I am NOT asking this question with an intent to get Jazz/RTC to "band backwards" to make the above happen. I AM however seeking a conceptual clarity regarding the way Jazz/RTC naturally views processes and tasks.
The documentation does talk about "workflows", but not in this sense of process flow. To me it looked more like the states that AN item moves from/to as actions are performed on it. A process step, in contrast, has many inputs, and may produce many outputs.
I also had a chat with a few Jazz/RTC "experts" in my neck of the woods, and they assure me that there is no way to naturally model (without writing all kinds of scripts/queries etc) the sample flow that I narrated above. Also, I am told that there is no natural way to make a person aware of when it is their turn to act once their predecessors have completed their activities.
I am sure that I am missing something, because if such basic capabilities are not supported in a natural way, how is any "process automation/control" to be achieved? And how is this tool is being used in used in real projects with tens/hundreds of participants?
"Bottom line":
Are my assumptions/expectations wrong? Is there an equivalent and alternate philosophy that Jazz follows, and I need to look at the tool that way? Do the "experts" know what they are talking about?
Can someone please help clear my mind and/or point me to resources that can provide answers.
|
3 answers
RTC of itself does not implement nor enforce any particular high level requirements to delivery model.
You can use many of the parts to implement a complete auditable process, but it is on you to do so. Requirements gathering and elucidation is the purpose of Requirements Manager Quality definition and verification is the purpose of Quality Manager. If you need higher level requirements portfolio mgmt, then you need to add FocalPoint to the mix. If you need Architecture and design storage and facilitation, then you would add System and/or Software Architect. RTC's job in the middle is to allow the development team to take validated requirements (see Focal Point and RM), with whatever certification you choose, and organize the work into waterfall (one big iteration) or agile (many small iterations) or kanban (like waterfall, but with a developer driven on demand processing model). RTC provides raw artifacts to help document and organize the work, Epic, Story, Task, Defect, Impediment, Adoption Item and Retrospective. You can add more as suits your needs. Inside each artifact is a processing model which is very neutral out of the box, but can be customized however you desire. but it is INSIDE the artifacts. there is no mechanism to implement nor enforce a higher level workflow or business process like u describe. Some consider Kanban to support a high level business process (deliver working function x to customer y), and the work (collection of epics, storys, tasks), flow thru the high level steps (requirements elucidation, planning, development, test, delivery), and the task board shows where in the high level workflow the collection is. RTC does not provide that high level flow model. How does this work with a "real projects with tens/hundreds of participants? ", the high level process is managed somewhere else.. but if u step back they are all the same. requirements in, process in the middle, content out. the artifacts used for each stage are fairly similar, almost identical in each processing model. discrete units of work with predictable ins and outs (if the actors do their tasks properly and to completion). " Also, I am told that there is no natural way to make a person aware of when it is their turn to act once their predecessors have completed their activities. ". correct,. that is because the model here is COLLABORATIVE Lifecycle Mgmt. all the actors are assumed to be actively engaged all the time, regardless of the central development process, and thus they participate in the work constantly.. there is no 'when it is their turn'. it is ALWAYS their turn. the engine here constantly takes inputs and delivers outputs. requirements mgmt delivers new work, development takes it as fast as possible, and delivers to the verification and delivery stages as fast as they can, verification and delivery are always working on the stuff coming down the conveyor belt to them. this is an assembly line. no 'beginning, middle or end', just a constant flow. (many iterations). the entire team meets constantly (daily standups) to articulate how the gears of the process are engaging (or not). you can decide to do this whole thing once (waterfall) or not (agile). Jazz provides the framework such that all the components of a complete lifecycle can communicate and participate in the large process (regardless of the specific model being executed) thur standard (OSLC) interfaces in the hope that this will reduce the integration workload to the business process and not the glue layer (point to point integrations) between them. "Now, lets say that the project moves from "planning" phase (say, for Release 1) to the "doing" phase for that release." there is no delineation here. the actors with planning responsibility are always planning and the executors are always executing. you 'could' implement a formal delineation, by using new artifact. and using workitem approvals to document the facts. but RTC does not provide this out of the box. |
|
Thanks for the reply.
I get the basic idea. Can you point me to a good starting point to get more familiar with this approach?
Without in any way deviating from the collaborative approach, it should be a basic feature that the work automatically moves down the assembly line, correct?
I am imagining that I am a solution architect Y waiting for requirements gathering to finish. Say, the plan says that X should send his work to Y. Is there a way for a planner or manager to capture this intent in Jazz?
Let's now say the business analyst X in my area has completed the creation of the requirements doc. How does the work come to Y?
Possibilities I can think of...
1. X marks his work as complete and the engine automatically delivers work to Y's "inbox" since that is the plan (assuming this intent can be captured in Jazz). Y sees it in his "inbox" and starts work on it.
2. X has to actively push his work to Y via Jazz/RTC. Kind of like email but with maybe some more controls. Y see it in his "inbox" and starts work. This implies that at his discretion X, (and not the planner) can choose to deviate from the process intent and send his work to another architect Z (I am assuming that at least some role based controls are possible).
3. X completes his work and walks up to/calls/emails/IMs Y to let him know that he can pick up work. This is how things work when there is no workflow system. Essentially the workflow triggers happens outside the system. Again, this implies that at his discretion X can choose to deviate from the process intent and send his work to another architect Z (I am assuming that at least some role based controls are possible).
4. X completes his work and informs the planner or manager M. M does either option 2 or option 3.
Which of the above reflects Jazz behaviour?
What would be problematic is for Y to see ALL the work planned for him over current iteration ALL the time. I.e. When he looks at his dashboard there is no way for him to know what he has to do without checking every single item every time. I am assuming that this is NOT how the tool works. Sharepoint plus email would be a better alternative.
Can you please clarify?
|
|
>I am imagining that I am a solution architect Y waiting for requirements gathering to finish. Say, the plan says that X should send his work to Y. Is there a way for a planner or manager to capture this intent in Jazz?
there is no way to capture this intent in the out of the box system. and he should never be 'waiting'. there was A requirement completed. It shows in the list of new workitems for architects and he take he next one to work on. the part of 'it shows in the list of new workitems' can be automated (scripting, coding, out of line workflow tools), but is not automated out of the box. each user has a dashboard of work assigned to them, each workitem has a priority, so the user could sort the dashboard (aka inbox) in priority order. so it is really like 4. 4. X completes his work and informs the planner or manager M. M does either option 2 or option 3. I'll call it 5. X completes his work. The planner or manager M (can be), informed of completed work does either option 2 or option 3. the default mechanism is the use of a query on the planner/manager M dashboard that shows completed work of type X. and their process step is to assign next steps to an actor. or you could have 6. X completes his work. Actors q, t, y and r see the list of current and incoming work, and decide among themselves who will take what part of that. (assign it to themselves) the Kanban view is to show where the work it at a higher level.. a) sitting in the incoming queue b) being worked on c) completed. a & b can be analyzed ad infinitum as to the causes for delay or expediency. all of this presupposes a creation of discrete units of work of the appropriate types in advance. this is the work decomposition phase, which is required of any project. RTC's workitems (out of the box), encapsulated in each project area are really the lowest level elements. I am not a formal process engineer. IBM has tooling to help in this space: Rational Method Composer and there is a connection with RTC (ie use MC (aka RUP) to create the model, then create a matching project area process description. here is a workshop I found (google) to assist in the use of MC and RTC to create that higher level process model. Process Composer workshop but you must do the process creation. (there may be models available already) |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.