Process and Service Management
Process Improvement Development Estimates
Quick Reference
Process Improvement Development Estimates
Use this document to aid in providing estimates for development of Business Process Modeling and process improvement
deliverables. These are not absolute development times. The values used for each project vary due to many factors. The
estimates are for the completed deliverable and include the actual development hours. They do not include meeting time,
time waiting for review edits, and other unrelated activities that are involved in a typical workday.
Important Considerations:

While the estimates should aid project managers in project planning, 40 hours does not generally mean one
week. With balancing multiple projects and priorities, the standard review processes (later in this document),
and ongoing system changes, 40 hours can mean anywhere from two weeks to several months.

Process analysis projects vary greatly in complexity and impact. Add time to the work effort for high-profile
projects or projects that involve many hand-off points.
References:
The Basics of BPM Project Planning by BPM Enterprise.com
Key:
These estimates represent development hours per deliverable and take into consideration common dependencies
such as complexity, risk, impact, and length.
Low estimates generally apply when the project is small and contained, when the Business Process Analyst is
also a subject matter expert for the process, or the process contains a relatively small number of steps.
Average estimates apply when a project is moderately complex.
High estimates generally apply to new and complex projects, and creating new deliverables “from scratch”.
Supporting Materials:
The Process Improvement team may need to develop performance support materials to enable teams to implement
proposed process improvements. Refer to the Performance Support Development Estimates Quick Reference for
those deliverables.
Deliverable Type
Estimated Work Effort (Time)
Low
Process Flow Diagram
The interactive flowcharts have two main purposes:
1. Provide a visual representation of work processes
2. Provide access to and organization for work procedures
Average
High
Estimated Development Hours
Per Page
NewCreate diagrams from scratch. These time estimates are for the
final draft and include the first draft, reviews, and revisions.
6
8
10
EditsRevise existing diagrams.
2
4
6
Last updated: Document1
1 of 2
Information and Technology Services
Process and Service Management
Process Improvement Development Estimates
Quick Reference
Deliverable Type
Estimated Work Effort (Time)
Low
Business Process Management
Business Process Management Process
Average
High
Estimated Number of Weeks
Per Project
8
12
24
Scope ProjectDocument goals and objectives, determine
identify issues, concerns, and pain points, etc.
1
2
3
Gather Current State ProcessReview existing process
information, identify roles, conduct interviews, etc.
2
3
6
Analyze Current State ProcessBaseline current process,
determine benchmarking opportunities, select analysis
approach, and execute analysis.
2
2
5
Model Future State ProcessIdentify and document proposed
alternatives to the current process, and the control,
measurement, and management components.
1
2
4
Document Process Improvement RoadmapProvide training
and support materials for the new process selected. (See
development estimates for support materials below.)
2
3
6
Review Process:
Most deliverables require several review cycles, including:

Peer review—review by senior members of the BPM team (average turnaround time 3-5 business days).

Internal review—review by key stakeholders, BSAs, designated internal reviewers (average turnaround time
5 business days).

External review—review by U-M customers or employees external to ITS (average turnaround time 5-10
business days).

Final (internal or external review) —review by any reviewer who may need to see the document after the
first round of edits have been incorporated (average turnaround time 3-5 business days).
Additional review cycles may be required depending on the needs of the project. The ultimate need is to obtain signoff by key stakeholders. Deliverables cannot be published until required reviews and approvals are completed and
recorded.
Last updated: Document1
2 of 2