Hi,
I’m new to PMstudent and I’m developing my interest in Project Management.
Currently, I am involved in a task of trying to identify possible deliverables for an Alternative School Program with an objective to help young people unleash their intelligence and positive energy to rebuild their communities and lives through the program. Can anyone suggest possible Deliverables for this program?
The Alternative School Program is designed and targeted towards young, low-income people between the ages 18-25 where they can work towards their high school certificate while learning job skills like building affordable houses for other homeless and low-income people. Strong emphasis will be placed on leadership and community service.
I am asking about what the deliverables of this particular project could/should/would be since I’m new to Project Management and the word ‘Deliverable’ in particular. I would like to know exactly how to identify deliverables properly for my projects and how to arrive best at the deliverables myself.
I would also like to know about deliverables for a project to set up the Alternative School Program. I’ll be starting a degree program in Project Management next year and would like to start learning right now.
[Editor: I want to thank Aniekan for having the courage to post in order to learn about project management! This sounds like an excellent endeavor.
My first comment is to not get caught up in terminology yet. If you have someone who you are working for, be sure you understand the initial goals from their perspective. Make a list of what you will do and will not do as a part of this project based on those high-level goals. You can write this up as a preliminary scope statement, but there are many ways to go about all these things.
Write those high-level things you will do in the form of outputs...products or services. There
may only be a few. Then break down these items by thinking through what it will take to produce them. Keep breaking them down until they can be effectively managed and executed.
In the end, you will probably find that some of the high-level things are deliverables for the project, and some are lower-level things you came up with.
This is a simple way to do it that I laid out based on my (very limited) understanding of your situation. There are many other ways to approach it. I have found, however, that it is best to approach a new subject like this one step at a time. Great project managers take decades to grow.
Please, everyone else lend your advice to our new friend as well. Thanks!]
Related posts:
{ 8 comments… read them below or add one }
Aniekanekah –
First, as a matter of courtesy, how would you like to be addressed? I used the full name from “About the Author,” but Josh addressed you as “Aniekan.”
Second, and more importantly, I think the VERY first thing that you need to do is some basic scoping. I define “scope” as the characteristics of the product of the project, and I differentiate that from “work” which is what you have to do to create the product of the project. In this case, you have at least one project (developing the ASP … let’s call it GRASP for Generating the Reality of ASP) and one of the outputs (deliverables) of that project will be a description of what and how (scope and work) for the projects or tasks that will be part of ASP.
In addition, you must recognize that the scope of GRASP will be variable and fluid. In some ways, it will really be a big design phase and the design may change frequently as you discover more about your sponsors/funders and your potential grantees.
Another key … your customers are NOT the young adults who will benefit from the program. Your customers are the individuals and/or organizations that will provide funding to ASP. The world of not-for-profit is littered with failed organizations that failed to grasp this idea.
Regarding “deliverables” … this is a somewhat regrettable term since it doesn’t translate well from English into other languages (Russian and Chinese are two that I know struggle with this term). But think of a deliverable as a “thing.” That thing could be a report, a document, a manufactured item, whatever. It can be produced for internal use (a status report) or for external distribution (an email that goes out to potential contributors). I also like to identify “key deliverables” as the items that will actually be used once the project is complete. In the case of GRASP, your key deliverables might be a vision statement for the organization, a business plan with 3-5 years of project financials, and possibly the documented results of a pilot program to provide proof of concept.
Duncan
Aniekanekah –
First, as a matter of courtesy, how would you like to be addressed? I used the full name from “About the Author,” but Josh addressed you as “Aniekan.”
Second, and more importantly, I think the VERY first thing that you need to do is some basic scoping. I define “scope” as the characteristics of the product of the project, and I differentiate that from “work” which is what you have to do to create the product of the project. In this case, you have at least one project (developing the ASP … let’s call it GRASP for Generating the Reality of ASP) and one of the outputs (deliverables) of that project will be a description of what and how (scope and work) for the projects or tasks that will be part of ASP.
In addition, you must recognize that the scope of GRASP will be variable and fluid. In some ways, it will really be a big design phase and the design may change frequently as you discover more about your sponsors/funders and your potential grantees.
Another key … your customers are NOT the young adults who will benefit from the program. Your customers are the individuals and/or organizations that will provide funding to ASP. The world of not-for-profit is littered with failed organizations that failed to grasp this idea.
Regarding “deliverables” … this is a somewhat regrettable term since it doesn’t translate well from English into other languages (Russian and Chinese are two that I know struggle with this term). But think of a deliverable as a “thing.” That thing could be a report, a document, a manufactured item, whatever. It can be produced for internal use (a status report) or for external distribution (an email that goes out to potential contributors). I also like to identify “key deliverables” as the items that will actually be used once the project is complete. In the case of GRASP, your key deliverables might be a vision statement for the organization, a business plan with 3-5 years of project financials, and possibly the documented results of a pilot program to provide proof of concept.
Duncan
Aniekan (Bill and others).
While delievrables may not be the right word in some languages, there are other issues that need to be address prior to building the WBS mention in the editors sub-post. The issues associated with a WBS centric project structure are well understood in some domains – aerospace and defense being the most mature.
In this domain (A&D) the Concept of Operations comes first. In your example: What is the concept of operations? What is the Alternative School Program DO, when its up and running? What does it look like operationally?
The answer to that, usually in the form of a Concept of Operations document, then generated a list of Needed Capabilities. These are “things” – products, services, staff, facilities, and other tangible and possibly intangible elements – that must be in place before the operational parts produce the desired outcomes.
From the Capabilties comes a set of requirements. Words like “shall,” “will,” “must,” are associated with requirments.
From these requirements, you can start to define the deliverables.
But it is critically important to not build the WBS in the absence of these pre-conditions. As important is to “test” the WBS with question like “if I had this thing – the deliverable – what woudl I do with it?”
A final note is that in the large system integration, complex systems, and product development worlds in many business domains, the WBS is a cost collection mechanism, for one simple reason.
Rarely is ever are products or services (represented in the WBS) decomposed in a nice, neat, structured tree. They are very often networks of interconnected dependent parts. This topology is very poorly server by the tree decomposition of the WBS.
So representing your service sructure in a tree is probably not the starting point. Draw a simple diagram of boxes and lines, in the boxes are Verbs on the lines Nouns. Use this diagarm as the basis for asking operational questions: “how would I deliver this services with this capabilitis in place, and what requirements woudl that call into play, ….”
This operationalization approach is how vague, evolving, and changing systems are developed in todays “systems” world.
Glen B. Alleman
VP, Program Planning and Controls
Aerospace and Defense
Denver, Colorado
Aniekan (Bill and others).
While delievrables may not be the right word in some languages, there are other issues that need to be address prior to building the WBS mention in the editors sub-post. The issues associated with a WBS centric project structure are well understood in some domains – aerospace and defense being the most mature.
In this domain (A&D) the Concept of Operations comes first. In your example: What is the concept of operations? What is the Alternative School Program DO, when its up and running? What does it look like operationally?
The answer to that, usually in the form of a Concept of Operations document, then generated a list of Needed Capabilities. These are “things” – products, services, staff, facilities, and other tangible and possibly intangible elements – that must be in place before the operational parts produce the desired outcomes.
From the Capabilties comes a set of requirements. Words like “shall,” “will,” “must,” are associated with requirments.
From these requirements, you can start to define the deliverables.
But it is critically important to not build the WBS in the absence of these pre-conditions. As important is to “test” the WBS with question like “if I had this thing – the deliverable – what woudl I do with it?”
A final note is that in the large system integration, complex systems, and product development worlds in many business domains, the WBS is a cost collection mechanism, for one simple reason.
Rarely is ever are products or services (represented in the WBS) decomposed in a nice, neat, structured tree. They are very often networks of interconnected dependent parts. This topology is very poorly server by the tree decomposition of the WBS.
So representing your service sructure in a tree is probably not the starting point. Draw a simple diagram of boxes and lines, in the boxes are Verbs on the lines Nouns. Use this diagarm as the basis for asking operational questions: “how would I deliver this services with this capabilitis in place, and what requirements woudl that call into play, ….”
This operationalization approach is how vague, evolving, and changing systems are developed in todays “systems” world.
Glen B. Alleman
VP, Program Planning and Controls
Aerospace and Defense
Denver, Colorado
Aniekan, as you can see there are many different ways to approach this. In some cases I think Bill, Glen, and I are essentially talking about the same things, using different terms.
I said “be sure you understand the initial goals from their perspective.”
Bill said “I think the VERY first thing that you need to do is some basic scoping.”
Glen spoke in terms of operational capabilities and requirements as first steps. Working in A&D myself, we also follow this with an Ops Con, etc. and the general process Glen described.
The general theme here is that you must understand who is involved (sponsor, customers, stakeholders) and what the end state is supposed to look like when you’re done. Only then can you start trying to plan your work and the different types of deliverables that will be produced. There’s a whole range of practices as to how to go about this and document it properly.
Thanks again for posting Aniekan!
Aniekan, as you can see there are many different ways to approach this. In some cases I think Bill, Glen, and I are essentially talking about the same things, using different terms.
I said “be sure you understand the initial goals from their perspective.”
Bill said “I think the VERY first thing that you need to do is some basic scoping.”
Glen spoke in terms of operational capabilities and requirements as first steps. Working in A&D myself, we also follow this with an Ops Con, etc. and the general process Glen described.
The general theme here is that you must understand who is involved (sponsor, customers, stakeholders) and what the end state is supposed to look like when you’re done. Only then can you start trying to plan your work and the different types of deliverables that will be produced. There’s a whole range of practices as to how to go about this and document it properly.
Thanks again for posting Aniekan!
Yeah, I agree 100% with what Glen is saying. What I was trying to suggest is that the development of a “Concept of Operations” should, in your case, be treated like a project in its own right.
Duncan
Yeah, I agree 100% with what Glen is saying. What I was trying to suggest is that the development of a “Concept of Operations” should, in your case, be treated like a project in its own right.
Duncan