Who Should Create a WBS?
We've written before about Work Breakdown Structures (WBS), one of the most important components of any project plan. There are several types of WBS, with the Activity WBS and Deliverable WBS being the most common. The Deliverable WBS breaks down project deliverables and results in the project's scope baseline. What's the best way to create them and who should do it? The process of creating a WBS varies by organization, and tends to revolve around the roles and responsibilities of Project Managers (PM) and Business Analysts (BA). An increasingly common and productive division of labor for creating a WBS is for the PM to be responsible for the WBS and for BAs to have the role of creating them. Using the Project Management Institute's (PMI) definitions, responsible means who makes decisions about something and role means who does something.
A good Deliverable WBS articulates what customers need in response to a business problem or opportunity. Since BAs are skilled at uncovering customer needs, they are arguably in the best position to create a Deliverable WBS. Another way to think of this is that the deliverables contained in a WBS are high-level requirements. Who better than a BA to document the requirements for the project plan? Ultimately, the PM is responsible for them, but the role of creating a Deliverable WBS is increasingly done with success by BAs.
Data ModelingData requirements need to be gathered and documented for most software projects. Whether the process is done in your organization by a business analyst, data analyst, database administrator, or whomever. Whether your organization calls it data modeling, data requirements, logical data design, or whatever. These important requirements support and complement the more obvious business processes that can be documented with process models, use case models and others.
Data requirements are best documented with a logical data model. Avoid the temptation to "throw" data requirements in with other documents such as use cases. We've seen some of our training clients try this and fail.
A logical data model is usually produced using an entity relationship diagram (ERD), and/or with a class diagram, depending on whether your company employs UML (Unified Modeling Language) or not. (Parenthetically, an analyst would be well-served by knowing both kinds of modeling, but that's a subject of a future mentoring tip.) The ERD or class diagram is the preferred way to show the data elements in a business area, its relationships, and the attributes the entities contain. It's a diagram understood by a variety of project team members, although we don't recommend using it to verify requirements with business people. Clients often have trouble reading them, and it's a little like a house builder using a blueprint to verify the requirements with a homeowner. From experience, they can be intimidating and can cause requirements to be missed. Learn how to produce and read ERDs, and you'll have a practical industry standard tool in your toolkit. For more on how to perform data modeling, check out our next Data Modeling class.
Roles and Responsibilities
An important ingredient for success on any project or process is to establish clear roles and responsibilities. These terms often get mixed up, which only adds to the confusion. The clearest and most practical definition of these terms we've seen is from PMI ? Project Management Institute. They define a Role as what a person does, and Responsibility as what a person decides. For example, people often say a Business Analyst is responsible for gathering requirements for a project. Many, if not most, people would agree with that statement. Using PMI's definition, though, a BA is responsible for documenting the requirements, and makes decisions about how they are recorded or modeled. The customer is actually responsible for them; i.e., makes the decisions regarding what their requirements are.
Clarifying important roles and responsibilities at the start of a project can save precious time and prevent misunderstandings. A handy tool to facilitate this is the RACI chart. It stands for Responsibility, Accountability, Consult and Inform. For a free electronic template of a RACI chart, write to mentor@watermarklearning.com. Or, sign up for our course on Consulting Skills to Solve Business Problems to learn more about roles and responsibilities, and practice how to use a RACI chart.
Just when you think your job, business or industry is doing new or innovative things, a reminder comes along that its not quite so new as you think. The 16th century Japanese military strategist, Mushashi Miyamoto in his book “Nine Precepts of Mushashi Miyamoto” wrote nine guiding principles. His first one is “Do not think dishonestly.” Seems pretty obvious, doesn't it?
But, in project management and requirements analysis work, there are several applications of this wonderful precept.
- Don't say “yes” to a project request if you really mean “no.”
- Don't agree to a fixed project deadline if you know it can't be met.
- Strive to understand client requirements completely. Probe deeply until you really understand and don't pretend to know more than you do.
- Provide honest status reporting in tasks and deliverables.
- Make sure all scope change requests go through a formal process; don't think you can just “sneak it in.”
Students often ask in our Use Case Modeling classes “What’s the difference between primary, alternate and exception paths?” These are important parts of a use case narrative, made even more relevant by confusion in the industry.
The primary path of a use case is the usual, expected, and most common or desired path. It is the path that reaches the use case’s post condition. An alternative path is one that deviates from the primary path and may even reach an alternative post condition. An exception path is an error condition that will terminate a use case.
Here’s a simple analogy we like to use to help illustrate the concepts. Drive to work “normal” way (e.g. freeway, bus, etc.). An alternate path might be taking a different route or bus. Another may be picking up a co-worker or going to a different building on occasion . . . (could be alternate post condition). An exception is not getting to work – the car breaks down or you miss the last bus!
If you would like a use case template to help you, send a note to mentor@watermarklearning.com.
One of the significant barriers to requirements elicitation is the lack of trust between key clients and the business analyst or project manager. Trust usually takes time to develop. We may initially trust or mistrust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgments. Analysts and project managers don't always have time to let relationships develop.
One thing that can be done to build trust is to communicate bad news. If the project is behind schedule or needs more resources or if lack of stakeholder participation is slowing the project, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members immediately.
When defining or improving processes, it's essential to have clear and fixed boundaries for all processes. Since a process always transforms inputs to outputs, you can use them to help define the boundaries. Better yet, list the pre-conditions and post-conditions to get a better grasp of processes boundaries. A pre-condition specifies what is true for a process to begin, and a post-condition is what becomes true when the process is done.
For example, a process to buy a new car might need a pre-condition of the old car breaking down, or it might begin when your lease is 3 months from expiration, or it might be when the old car is 5 years old. A post-condition could be when an agreement with a car dealer is made, or after financing is complete, or it could be as late as when you take possession of the car. The pre- and post-conditions imply processing steps that must take place in the process, and are a huge benefit to defining the framework of any process. Don't define a process without them!
Before the formal requirements gathering begins, it is important to discuss the business context of the project with the sponsor. Requirements need to be gathered and managed in relation to the organization's vision and strategic direction. They need to link to business goals and objectives. When requirements do not have this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that are out-of-scope and that promote their own personal agendas.
Use Case Actors
When people are being considered as actors, it is important to understand that the people are playing roles (such as customer, maintenance worker, troubleshooting technician, installer, and manager), and they should be documented and described by those role names. You may find someone that may play more than one role, such as the following:
- Customer and employee
- Technician and manager
- Customer, account representative, and salesperson
It is important to think of actors as role players and not individual persons. Defining the actors by what interactions they wish to perform with the system will help separate the actors. In other words, the description of the interactions should define and substantiate the actors' existences.
As the use case gets refined, additional actors (roles) may split a current actor into two, depending upon how they wish to interact with the system or depending upon what they wish to accomplish with the system. This means that the number of actors may grow as use cases are identified and defined. A key to this process is ensuring that the definition of the actor remains constant. If the definition of the actor seems to change, depending upon the situation, there may be an additional actor that needs to be defined and documented.
The Project
Scope Statement is a living document. Your Sponsor
should know that the milestone dates are subject to
change until you have finished your detail WBS planning.
THEN, you manage your project to the WBS based dates,
and resource commitments associated with them. Update
the Scope Statement with any new milestone dates.
Always know who your key stakeholders are, and
form a good, trust-based, partnership with them. It
will pay dividends, such as, scope clarity, a higher
quality product, and a desire to help make the project
a success.
If
you want high quality task estimates, good Work Breakdown
Structure (WBS) planning is essential. Take each deliverable
in your scope statement and break it down to its lowest
level work packages. Define activities for each work
package. Look at each activity to see if you can break
it down into lower level tasks. Then make estimates
for actually doing the work on each task or activity
(if it can't be broken down any further). The resulting
estimates will be more accurate with this approach
than with any other. |
Mentoring options
Project Management mentoring tips
Business Analysis mentoring tips
Mentoring home
|
