© 2017 by QS2 Point

  • Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Black Circle

September 18, 2019

Please reload

Recent Posts

Translating Requirements to Work Packages

September 18, 2017

1/5
Please reload

Featured Posts

Translating Requirements to Work Packages

September 18, 2017

 

The first major phase of most project is defining the overall scope and requirements of what it is the customer is seeking to achieve with the project. Once the stakeholders have been engaged, requirements documented, reviewed and approved we have our project framework. At the end of requirements gathering your team and customer will have an agreed list of functionality that your team is tasked with delivering inside the scope of the project. Now comes the fun part (really) – turning those requirements into functional work packages for your team to execute. This is where the experience of a project manager shines through.

 

Create a Work Breakdown Structure (WBS)

 

Depending on the nature of your project, creating a WBS can help shed some light on defining not only what you need to do (correlating back to requirements) but more importantly – how  you are going to do it.  Performing a WBS should be done collaboratively as a group where tasks are discussed, defined, broken down and broken down even more. I will do another post on how to create an effective WBS but the objective of the activity is to flesh out the framework of a project plan with tasks broken down to a ‘bite-size’ level where team members can accurately estimate and deliver on the tasks in support of delivering the required functionality. This is the first step in having a defined list of work packages.

 

Engage Your Technical Lead

 

Once your project plan has been defined (via your WBS), getting your technical lead (or entire technical team) engaged is critical to determine what the architecture of the solution will look like, given the understanding of both the business requirements and the WBS (the what and the how) your technical lead should be able to put together an architecture and standards that the rest of the technical team will follow.

 

Build Work Packages

 

Once your project plan is defined (i.e. modules to be built), your architecture defined (how the building will happen), you and your team can engage in defining ‘work packages’ that comprise of the technical tasks, matched up to business requirements (and possibly testing plans). By having fully fleshed out work packages that can be assigned/taken by the team, it not only empowers your team members to take full ownership and accountability of the work package but it also helps with the overall management of the technical components of the project by having work packages aligned with business requirements.

 

Whether in an Agile or Waterfall environment, this approach absolutely allows for more streamlined management and reporting of your project progress. Issues, risks can be attributed directly to work packages and/or the related requirements allowing for quicker, easier resolution of the issues. Customers can have a better understanding of true progress of the project (showing a list of work packages and statuses can be much more informative than a simple % complete).

 

Want to learn how our Digital Experience service can help you and your team? Let's talk!
 

Share on Facebook
Share on Twitter
Please reload

Please reload

Archive