Regarding the WBS of an integration project of migrating an app from a platform to another (no hardware procurement involved), say I decomposed the project as follows: The first level is the project name. The second level is the development life cycle: 1.1 Requirement 1.2 Assessment (to determine dev(app team) and platform(arch/eng team) adaptation for a smooth migration 1.3 Architecture 1.4 Migration 1.5 Transition Ex of the subsequent level of deliverables for example for Requirement work package are: 1.1.1 Functional and non-functional requirements 1.1.2 Compliance requirements (Monitoring&Security requirements) 1.1.3 Transition requirements
Can you give an example of acceptance criteria for the work packages (say 1.1.1 or 1.1.2 )
I thought that when I'm gathering the requirement lists which will specify values for future test execution (ex post-migration), they cannot be used as acceptance criteria for the work package. However, I thought that Architect SME doing his inspection and verifying the completeness and correctness of data would be a better acceptance criterion. That being said, I'm afraid that would be leading to subjective interpretation or bad surprises later on...
What do you think? what did I miss? how can I ensure that the above interim deliverables are accepted?
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Nice predictive approach.
Regarding 1.1.1 I would say quality assessment of a set of requirements would be a reasonable acceptance criterium.
Quality could be assessed if the requirements are complete, consistent (not contradicting), testable, unambiguous, assigned to specific stakeholders, aligned to the project goals, prioritized etc.
This is why if I'm developing a WBS (as opposed to a story map) with my team, I'd use a deliverable-based decomposition rather than a phase-based one as it is a bit easier to identify the acceptance criteria.
Also, acceptance criteria tend to be used to refer to things that add value to a stakeholder. Work packages may be a component of something which adds value but not necessarily value in and off themselves (hence the difference between a user story and a work package).
As such, you may find that there are quality considerations for work packages but true acceptance criteria for nodes in the WBS above the work packages...
Kiron
...
1 reply by Soha Karjawally
Jun 14, 2020 8:32 PM
Soha Karjawally
...
Thanks, Kiron.
That's why I was thinking that some real acceptance criteria can be at the node level (closer to stakeholder and sponsor expectations) although we go deeper to define the lowest work package.
Anyways, that confirms that the quality assessment I was planning to do to validate the gathered requirements would be adequate.
Btw, the team isn't necessarily PMism, so kinda having all hats to make the job done.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Those are the easy to define an acceptance criteria: project quality activities. First of all, take a look to the definition of acceptance criteria and mainly the components which are two: the acceptance criteria and the process to validate it. For example, suppose you are creating a light bulb. The acceptance criteria could be "1000 hours of life of use" and the process could be "tourn it on-off by 1001 hours". Second, you create acceptance criteria from product requirements because you define project quality from product requirements. You have basically two type of product requirements: functional and non-functional. The best source of information about it inside the PMI documentation is the Practice Guide for Business Analysis. But you will find a lot on the matter for example if you look for Karl Wiegers work.
...
1 reply by Soha Karjawally
Jun 14, 2020 8:38 PM
Soha Karjawally
...
Thanks, Sergio. Indeed I have Wiegers's book (Software requirements 2) and I went through it yesterday to see if I'm missing something. I will eventually check also Practice Guide for Business Analysis.
And, excellent point about the acceptance criteria and the process to validate it. In my example, it would be the values coming from today's architecture and the process would be dedicated tests provided by the related teams to validate we meet them.
As Kiron suggested, a story map or list of deliverable epics is a much better way to start. Phasing is best avoided on any software project. I also suggest you consult the team as soon as possible. The team should own the plan and there's probably nothing to be gained by imposing a structure on a suitably knowledgeable and experienced team. Saving Changes...
Coming from a Systems Engineering discipline, along with the WBS, there would also be a requirements decomposition in tree form like the WBS, a physical architecture (what are the components of your app), a logical architecture (how it works such as process flow diagrams), and a functional architecture (what it does).
For 1.1.1 and 1.1.2 you would validate that your requirements are complete, clear, and correct. Many of the requirements are derived from the architecture views such as the components (e.g. storage size), functions (e.g.frequency of back-ups), and processes (e.g. prevent deadlock). Part of your validation might be mapping the requirements to their associated architectural elements for traceability.
This can be easier if the WBS is aligned to the physical architecture or deliverables as Kiron describes. Using that method, you have component level requirements, subsystem level, system level, product level, etc. where components work together to perform functions at various levels of the architecture.
...
1 reply by Soha Karjawally
Jun 14, 2020 8:41 PM
Soha Karjawally
...
Very interesting input. Thanks, Keith.
One thing is unfortunately we don't have all the exact documentation as we would love to and you probably know that in some cases, such apps were in the hand of consultants who left and no one knows all details. so it is a kind of challenge at the same time and reverse eng.
Regarding 1.1.1 I would say quality assessment of a set of requirements would be a reasonable acceptance criterium.
Quality could be assessed if the requirements are complete, consistent (not contradicting), testable, unambiguous, assigned to specific stakeholders, aligned to the project goals, prioritized etc.
Thanks, Thomas. This is helpful. Saving Changes...
This is why if I'm developing a WBS (as opposed to a story map) with my team, I'd use a deliverable-based decomposition rather than a phase-based one as it is a bit easier to identify the acceptance criteria.
Also, acceptance criteria tend to be used to refer to things that add value to a stakeholder. Work packages may be a component of something which adds value but not necessarily value in and off themselves (hence the difference between a user story and a work package).
As such, you may find that there are quality considerations for work packages but true acceptance criteria for nodes in the WBS above the work packages...
Kiron
Thanks, Kiron.
That's why I was thinking that some real acceptance criteria can be at the node level (closer to stakeholder and sponsor expectations) although we go deeper to define the lowest work package.
Anyways, that confirms that the quality assessment I was planning to do to validate the gathered requirements would be adequate.
Btw, the team isn't necessarily PMism, so kinda having all hats to make the job done. Saving Changes...
Those are the easy to define an acceptance criteria: project quality activities. First of all, take a look to the definition of acceptance criteria and mainly the components which are two: the acceptance criteria and the process to validate it. For example, suppose you are creating a light bulb. The acceptance criteria could be "1000 hours of life of use" and the process could be "tourn it on-off by 1001 hours". Second, you create acceptance criteria from product requirements because you define project quality from product requirements. You have basically two type of product requirements: functional and non-functional. The best source of information about it inside the PMI documentation is the Practice Guide for Business Analysis. But you will find a lot on the matter for example if you look for Karl Wiegers work.
Thanks, Sergio. Indeed I have Wiegers's book (Software requirements 2) and I went through it yesterday to see if I'm missing something. I will eventually check also Practice Guide for Business Analysis.
And, excellent point about the acceptance criteria and the process to validate it. In my example, it would be the values coming from today's architecture and the process would be dedicated tests provided by the related teams to validate we meet them.
...
1 reply by Sergio Luis Conte
Jun 14, 2020 9:16 PM
Sergio Luis Conte
...
You are welcome. Karl work can be used for non software products too. Additional to that take a look to V Model (there is a book called "Visualizing Project Management") which is a model created long time ago and it is used by all type of products including that is the model adopted "under the hood" by things like SAFe and DevOps
Coming from a Systems Engineering discipline, along with the WBS, there would also be a requirements decomposition in tree form like the WBS, a physical architecture (what are the components of your app), a logical architecture (how it works such as process flow diagrams), and a functional architecture (what it does).
For 1.1.1 and 1.1.2 you would validate that your requirements are complete, clear, and correct. Many of the requirements are derived from the architecture views such as the components (e.g. storage size), functions (e.g.frequency of back-ups), and processes (e.g. prevent deadlock). Part of your validation might be mapping the requirements to their associated architectural elements for traceability.
This can be easier if the WBS is aligned to the physical architecture or deliverables as Kiron describes. Using that method, you have component level requirements, subsystem level, system level, product level, etc. where components work together to perform functions at various levels of the architecture.
Very interesting input. Thanks, Keith.
One thing is unfortunately we don't have all the exact documentation as we would love to and you probably know that in some cases, such apps were in the hand of consultants who left and no one knows all details. so it is a kind of challenge at the same time and reverse eng.
...
1 reply by Keith Novak
Jun 15, 2020 9:56 AM
Keith Novak
...
Although you may not have the original documentation, you don't necessarily have to reverse engineer it either.
At the end of your project, hopefully you will have some way to say the app works. How do you do that? You define what "it works" means to you.
In a gig working a very large digital transformation project of a configuration management system, some of the old systems were so archaic nobody really knew how they worked. Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source.
This is similar to if you work in an enterprise level integration department and you are implementing new COTS software. The documentation is proprietary and you can't get it. The software has far more applications than you need. In that case you are not ensuring all the software works, but rather only the parts you need to use.
When you are working with an existing product, you don't necessarily have to verify all the requirements, test out all the functions, or even know how it all works. You do however have to validate that you know what requirements and functionality you care about, so that it will perform as expected when you buy off on the deliverable.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Jun 14, 2020 8:38 PM
Replying to Soha Karjawally
...
Thanks, Sergio. Indeed I have Wiegers's book (Software requirements 2) and I went through it yesterday to see if I'm missing something. I will eventually check also Practice Guide for Business Analysis.
And, excellent point about the acceptance criteria and the process to validate it. In my example, it would be the values coming from today's architecture and the process would be dedicated tests provided by the related teams to validate we meet them.
You are welcome. Karl work can be used for non software products too. Additional to that take a look to V Model (there is a book called "Visualizing Project Management") which is a model created long time ago and it is used by all type of products including that is the model adopted "under the hood" by things like SAFe and DevOps Saving Changes...
