Business Analysts (BA) are tasked with reducing requirements timeline in a project life cycle as much as possible. However, BAs know all too well the issues in realistically identifying project activities and tasks. Both the Development and Quality Assurance (QA) staff’s project timelines are contingent upon the BAs delivery of requirements artifacts. Ultimately the success of the entire project hinges upon the correctness and timeliness of the BA deliverables.

1. Project Estimating…The Squeeze is On
Shirley J. Sartin, PMP
Introduction
Business Analysts (BA) are tasked with reducing requirements timeline in a project life
cycle as much as possible. However, BAs know all too well the issues in realistically
identifying project activities and tasks. Both the Development and Quality Assurance
(QA) staff’s project timelines are contingent upon the BAs delivery of requirements
artifacts. Ultimately the success of the entire project hinges upon the correctness and
timeliness of the BA deliverables.
In order to successfully meet the project team’s expectations, the BA management and
staff should consider the following when estimating project tasks and durations:
• Project Methodology
• Project Involvement
• Project Phases
• Customer Reviews
• Collaboration
• Peer Review
• Task Estimating
• Estimating Template
Project Methodology
To provide a BA with an understanding of project expectations, Project Management
(PM) methodology training should be considered for all BAs in the organization. This
includes an overview of PM methods used by the organization and should at a minimum
include the following discussions:
• PM methodology phases
• Deliverables for each phase
Although an IT organization may not have adopted a specific PM methodology, they
should consider adopting best practices of the PM Body of Knowledge (BOK) and
incorporating them into their Software Development Life Cycle (SDLC).
Project Involvement
Those BAs assigned to a project as early in the project as possible are enlightened BAs.
They will have a better understanding of the project goals, etc. In the case of a very large
project, it would be helpful to assign a primary BA and, if possible a secondary BA. The
primary BA would act as a project Subject Matter Expert (SME) to the secondary BA.
The secondary BA could be involved in the project only as necessary and assist with
creating and/or writing specific use cases and requirements specifications for individual
screens, etc. This is similar to a lead developer divvying up coding tasks to secondary
coders.
1/25/2006 Page 1 of 7

2. Project Phases
Most organizations require a BA to define solution features. In order to provide value to
the developed solution, the BA should consider the following when building this feature
list:1
• Does the feature help the customer?
• Will this feature add quantifiable value?
• What is the goal and is it realistic?
• How can the feature be tested?
The BA should consider only a few features early in the project and then progressively
refine these features within the use cases, etc. as analysis progresses. Project Managers
understand a certain confidence level exists at different phases of a project. As the
project progresses and refinements occur, estimating may be revised.
With the feature list in mind and an architected solution drafted by the development staff,
the primary BA should be able to discern architecturally significant use cases. Although
some of these use cases may be extremely high level, they could be used to establish a
focus for the remaining project efforts by identifying analysis phases or chunks of effort
early into the project.
Customer Reviews
It is important to achieve customer buy-in on a project. Incorporating several customer
reviews in the project estimation will provide opportunities for presenting the evolving
solution and receiving feedback. Additionally, it is beneficial for the entire project team
to know that the customer has reviewed progress and has agreed to design decisions
during the course of the project.
Solution presentations or walkthroughs should be provided at completion of each chunk
of solution design prior to development. These walkthroughs will serve to ensure the
project’s goals remain on-track and any newly identified business requirements have
been incorporated into the overall design.2 The presentations do not have to be a formal
process with published artifacts, etc. The use of simple storyboards or paper screen
representations should be sufficient to initiate discussion.
Collaboration
A solution for the project’s goals/features doesn’t occur in a vacuum. It has proven to be
very helpful for the primary BA to be involved with as much discussion as possible
during the architectural design efforts. At the very least the primary BA should be
included so they may represent the businesses functional requirements (the what) – as
much as is known at that point in the project. Use case development should involve the
primary BA, the developer and the architect wherever possible. This will ensure
technically feasible process flows or scenarios while considering the customer’s needs.
1
Laura Rose, Twelve Tips for Realistic Scheduling in a Software Development Project, 15 July 2005,
http://www-128.ibm.com/developerworks/rational/library/jul05/rose/index.html, p. 7.
2
Laura Rose, Involving Customers Early and Often in a Software Development Project, 16 January 2006,
http://www-128.ibm.com/developerworks/rational/library/jan06/rose/index.html#notes
1/25/2006 Page 2 of 7

3. As previously mentioned, the BA should separately involve the customer for occasional
reviews at certain points in the evolution of the use case development. The customer does
not need to review a use case document until that artifact is ready to release. At that time,
the customer can review and provide approval/signoff.
Peer Review
Peer reviews should be considered for, at the least, sanity checks to ensure proper
development of the BA artifacts (for new applications being developed). In the case of
maintaining existing applications (new versions or enhancements), BA staff may have
sufficient knowledge of the application’s functions and can serve to provide a review of
analysis used in completing the artifact. This is similar to code reviews by development
staff.
Task Estimating
The BA needs to be concerned not only with task estimating but also interruption
estimating3. Most BAs are considered go to people and thus need to provide times for
project interruptions. However, in recovering from those interruptions the BA has to
consider and provide estimations for interruption recovery. For example, if a BA is in the
midst of developing a use case, an interruption can cause a disruption in their mental
processing of the use case flow. It will take additional time for the BA to recover their
thoughts and resume use case development.
However, by having previously determined chunks of effort, self-contained activities
within the identified chunks can be estimated while also providing time buffers (referred
to by PM as lead time and slack) between the self-contained activities and also between
the chunks. Although this appears to be padding the timeline, in actuality this is
providing for interruptions.
In case an interruption should occur in the midst of an activity the BA will know when
buffer time will be available and can request to deal with the interruption at a previously
determined stopping point. This will provide the time needed to deal with the issue. If
no interruption occurs then the BA can move onto the next activity/chunk and skip the
buffer. The buffer serves not only for dealing with interruptions but also provides time
for the BA to gather their thoughts before resuming with project efforts.
Should an interruption occur that must be dealt with immediately then the BA should
notify the PM and BA Manager with an estimated impact on the project, priorities, etc.
The BA had previously estimated tasks so they should be able to provide some idea of the
delay that may be realized. The PM can then review the project timeline and determine
the full impact to the project. In being prepared to handle these emergencies and provide
proper notification of potential project interruption, the BA is able to deal with the stress
of not performing as expected.
Estimating Template
A template4 for documenting/developing a detailed task list would be helpful. Since the
BA has been exposed to the company’s PM methodology and thus understands the
3
The interruption estimating concept, as suggested by Laura Rose is summarized here.
4
A template as initially described in Laura Rose’s article but expanded here for the BA methodology.
1/25/2006 Page 3 of 7

4. artifact development/delivery for the project phases, the BA will be able to utilize the
template to realistically identify project specific tasks and durations.
For example, most organization’s PM methodology provides for the following phases
along with associated BA artifact deliverables:
• Pre-Project
o Develop Business Proposal
Business Requirements
Scope
Stakeholders
o Facilitate Technical Proposal
Solution and Alternatives
Assumptions, Constraints and Dependencies
Critical Success Factors
Technical Risks
o Create Vision and Scope
Objectives
Features
• Define & Plan
o Vision and Scope
Objectives
Features
o Architecturally Significant Use Cases
o Business Rules
o Screen Mockups – High Level
• Startup
o Use Cases Completed
Normal Courses
Alternatives
Exceptions
Business Rules
o Screen Mockups – as related to the Completed Use Cases
o Software Requirements Specification (SRS)
Data Requirements
Functional Requirements
Non-Functional Requirements
• Execute & Control
o Updates to Use Case and SRS as needed
• Close
• Post-Project
o Review task estimations
o Document and revise base estimations for use in next project
1/25/2006 Page 4 of 7

5. Figure 1 Project Estimating Template could assist in estimating the BA’s tasks and
duration for a large project.5 This template should be considered only as a starting point
in estimating durations. Revisions should be made as needed based on the specific
project.
Figure 1 Project Estimating Template
Project Duration
Phase Task Name Activity (Days) Start Finish
Project Review all materials. Attend customer
Review meetings, etc.
Draft Business Proposal
Review Business Proposal
Proposal
Facilitate Technical Proposal
Pre-
Project Proposal Approval
Create Draft
• Objectives
• Features
Vision &
Scope6 Review draft with project team
Review draft with customer
Approve Draft
Identify Significant Use Cases
Define &
Identify Business Rules
Plan Use Case
Initiate solution screen mockups (hi- level)
Document
Review with project team
Review with customer
Screen Mockups – as related to the Completed
Use Cases
• Add detail
Use Case
Startup
• Determine logic flow
Document
• Apply Business Rules and Data
Relationship Rules
Review screen mockups with project team
Review screen mockups with customer
Use Case n Completed
• Normal Courses
• Alternatives
• Exceptions
• Business Rules
Use Case n+1 Completed
• Normal Courses
• Alternatives
• Exceptions
• Business Rules
5
This estimating worksheet is for use by the BA. The activities defined may be used as input into the
Work Breakdown Structure (WBS). However, before providing the Project Manager with a copy of the
estimations, care should be taken to roll up any separate lines for analysis activities or buffers into the
appropriate activity so the reserved time is not apparent in the Project Schedule.
6
The Vision and Scope task occurs during both the Pre-Project and Define & Plan phases of the project.
1/25/2006 Page 5 of 7

6. Project Duration
Phase Task Name Activity (Days) Start Finish
Peer review use case document
Review use case document with project team
Approve use case document (project team and
customer)
Use Case n
• Data Requirements
• Functional Requirements
• Non-Functional Requirements
Use Case n+1
Software
• Data Requirements
Requirements
• Functional Requirements
Specification
• Non-Functional Requirements
(SRS)
Draft SRS
Peer review SRS
Review use case document with project team
Review use case document with customer
Use Case
Execute &
Document & Updates to Use Case and SRS as needed
Control
SRS
Review Task Estimations
Post Lessons
Document and revise baseline estimations for
Project Learned
use in next project.
The BA should add rows to the table for activities related to specific project tasks and
also to identify self-contained analysis activities, project chunks or buffers (lead time and
slack) along with duration estimates. These items have not been included in the template.
Task Estimating
So how can a BA ensure their time estimates are on target? By maintaining a separate
task estimating worksheet during the course of a project the BA would be able to forecast
their efforts for the next project. By including notes for each of the task the BA could
track issues or interruptions that occurred. In reviewing this worksheet the BA would
have some understanding of the efforts that were involved in the project and could adjust
their estimates at the beginning of the next project.
The task estimating worksheet would be created early into the project and updated as the
solution evolves. Figure 2 Sample Task Estimating Worksheet, below is an example of a
requirements specification deliverable. A separate worksheet could be created for any
other project deliverables.
1/25/2006 Page 6 of 7

7. Figure 2 Sample Task Estimating Worksheet
Requirements Specifications Estimation
Duration = Hours
Front Matter
Begin End
Task Date Date Duration Analyst Notes
Data Requirements
Begin End
Task Duration Analyst Notes
Date Date
Functional Requirements
Begin End
Task Duration Analyst Notes
Date Date
Non-Functional Requirements
Begin End
Task Date Date Duration Analyst Notes
Implementation Requirements
Begin End
Task Duration Analyst Notes
Date Date
Summary
In order to avoid rework, the SDLC Analysis and Design phase should provide sufficient
time for project team BAs to identify features and functions and create detailed
requirements for Development’s and QA’s use. However, much pressure is on the BA to
complete their tasks quickly. It is hoped the suggestions herein will provide the BA a
manner in which they may provide an accurate, dependable estimation and no longer
stress over a misjudged timeline.
About the Author
Shirley J. Sartin is currently performing requirements analysis. Her 20+ years in IT have encompassed roles in
project management, systems analysis, business analysis, programming analysis, systems administration, operations
administration and technical training in a variety of industries. She is certified as a Project Management Professional
(PMP) and is striving towards gaining recognition and credibility for IT industry BAs. Shirley may be reached at
shirleysartin@hotmail.com.
1/25/2006 Page 7 of 7