A general direction has been set, a team of people assembled, they know what their first deliverables are, and they are off and running. They don't know what the end deliverable will look like, nor do they have a set of satisfaction criteria. Neither they nor their customers can say how long the work will last, and drip-feed development could go on for ever. They describe themselves as a project team, but are they really? And is their manager a project manager? Prince2 would suggest not, and I suspect that PMBOK would agree, but it is not an uncommon situation. If this is not a project, what is it?
8 Answers
If the team is working on an ongoing project or series of related projects, it's quite possible that this particular team is part of a program or part of product development.
Wikipedia describes a Program Manager as a person who manages multiple projects and who communicates with one or more project managers in order to meet a specific strategic goal.
According to Project Management Institute (PMI), The Standard for Program Management, 2nd Ed., "A Program is a group of related projects managed in a coordinated manner to obtain benefits and control NOT available from managing them individually. Programs may include elements of related work outside of the scope of the discreet projects in the program... Some projects within a program can deliver useful incremental benefits to the organization before the program itself has completed."
A Product Manager is someone who manages the development of products for an organization. In my organization, this role would best describe what I do, as I am handling cross-functional goals, including development, marketing, sales, customer service, and human resources. Below is the definition of a product manager from Wikipedia:
A product manager investigates, selects, and develops products for an organization, performing the activities of product management. A product manager considers numerous factors such as intended demographic, the products offered by the competition, and how well the product fits with the company's business model. Generally, a product manager manages one or more tangible products. However, the term may be used to describe a person who manages intangible products, such as music, information, and services.
Wikipedia also goes on to say that a product manager may also perform the duties of a program manager and/or a project manager as well as playing a leading role in supervising and setting goals for program and project managers.
In your scenario, your team and manager may cross the lines between being categorized as a product team, program team, or project team, depending on where you are in the process.
I may be breaking the fourth wall by adding this, but I also want to point out that Questions About Product and Program Management Are On-Topic Here.
-
I think that all of the answers have value, but in the particular case that I'm asking about, this is the answer that most closely fits the scenario. It's certainly not a research project, as there are customers, and I don't think they are an exploratory committee. They are indeed developing a software product, and while they know some of the short term deliverables, they just don't know where that product will end up, in terms of features, functionality, or customer benefits. In fact, one customer is helping them to develop the direction as an ongoing, two-way commitment between the parties.– Iain9688Apr 27, 2011 at 18:34
It depends on how orthodox you are going to be about project. If you take either Prince2 or PMBOK or Wikipedia definition it doesn't make a project.
However personally I'm far from being conservative on definitions and so are many people people out there, so I'd say it is a project.
Actually, many R&D endeavors works like that. Also, in many agile project, you don't have clear completion criteria or it is changing very often, like every couple of weeks -- it just depends how you look at the subject.
What more, if you asked people they would answer they are a project team. The client is probably describing this venture as a project. The vendor probably refers to it as a project as well, so who are we to disagree?
Besides, we don't get points, or get paid, for being conservatively aligned with definitions, whatever they are, but for making clients satisfied. So as long as everyone is happy, I see no issues with breaking rules of one or another specific project management methodology.
-
3That last paragraph really makes a lot of sense. If everyone is happy and things are successful, why rock the boat :)– jmort253Apr 24, 2011 at 19:01
It appears you have a Development Team in search of a Project. Their leaser would be a Development Leader. Unfortunately, too much development is done in this manner. However, it appears they do have a direction. Whether, their development approach is appropriate for the ultimate (apparently unknown) goal remains to be seen.
Not knowing exactly what the end deliverable will look like may be appropriate. Not knowing the scope of the project is not. What is the vision of the project? Are they building a bread box or a skyscraper? I would not want to be their customer, and it can be frustrating to develop in such a situation.
Once they have a project with a vision, scope, and satisfaction criteria, they will become a Project Team and their leader a Project Leader.
According to A Guide to the Project Management Body of Knowledge 7th Edition, a project be "a temporary endeavor undertaken to create a unique product, service, or result" and that the "temporary nature of projects indicates a beginning and an end to the project work".
If you have a definition of what the first deliverable is, then you may have a project that can be defined and managed to allow the team to work toward that deliverable.
There are a number of project management principles around engaging with stakeholders, navigating complexity, managing risk and optimizing risk responses, and enabling change to achieve the desired future state that could be applied to help the team identify the criteria for success of each deliverable and, eventually, the overall goals.
The PMBOK 7th Edition also defines the concept of program and portfolio. A program is a related set of projects and/or subsidiary programs that are managed together to get benefits. A portfolio is a group of projects, programs, and subsidiary portfolios managed to support strategic objectives. If you have multiple deliverables that are being worked toward, then you may be able to define and manage a program or a portfolio as well.
Personally I would call this a Research (project). But even for a research project, you must have some sort of goal, a problem you want to solve. Is there some stage/level you want to reach before you call it even a small success in its own right (no matter how long it might go on afterwards).
If you can identify a first step quite clearly, then you have it, it is a project.
Another way to look at it is to ask who calls the shots, who pays for it. Is there any criteria for pulling the plug? If there is a defined stage by which some form of result must have appeared or funds dry up and the project team must be dissolved, then there you go again, you have a set of criteria.
I understand that those criteria may not be hard and objective, but I don't know of many endeavours (including personal ones) that don't have some sort of tangible even subjective milestones to reach, for either self satisfaction, or as a decision point to go on to the next step, can the whole thing, or try a different direction.
projects could be categorized generally in 4 domain based on goals and the way of execution.
So, the answer is yes. there are some projects that their goal are not clear. On the other hand, there are some vision about direction and every body agrees about what should be done for the project. there are also some example for "making a movie" type of project:
However, goals ambiguity increase complexity and the project manager should address the relevant complexity and risks. The project manager's role for this kinds of projects is to help the team craft a viable solution, whilst encouraging innovation and retaining a degree of flexibility within agreed milestones. in this way, some projects management frameworks are developed to control these kinds of projects.
-
1It would be better to write the content in the images as text in the answer. Dec 21, 2022 at 22:41
-
I've read this several times and I'm not clear what you are asking or how to answer (I think that's the upper right quadrant, lost in the fog). please clarify– MCWDec 24, 2022 at 19:40
There are five immutable principles of all projects: 1. Done is defined; 2. A way to get to done is known; 3. Resources to get to done are known and available; 4. Obstacles getting to done are known and mitigated; and 5. A way to measure progress getting to done is known and used.
However, #1 does not have to be known for the final final product that could be years down the road. Agile is based on that. So, too, in what many mistakenly call traditional waterfall. Progressive planning does exist, which includes defining done for whatever the next phase might be. But if you don't have #1 defined at least to some interim finish, then how can you do numbers two through five? A project, for it to be a project, needs to have some definition of done to some defined point in time but does not have to be the final final done done finished finished product.
If the "team" is not working against a defined list of features with acceptance criteria inside of a specified time horizon, they aren't a project team, they are an exploratory committee working on a "spike" (to borrow a term from XP). While completely acceptable, "spikes" are exercises undertaken by a project team when they need more information to better understand the product they are developing and any underlying technical challenges so that they can provide better estimates and risk evaluations.
Someone, somewhere is paying the freight for this effort - they might have some expectation of ROI. How do you define ROI if you have no means of measuring outcomes like what you're building or if it was successful? Agile/lean/iterative/incremental processes are best suited in situations where the end goal is understood but not necessarily how to get there: Risk is managed by continually inspecting and adapting within short time horizons - without goals, this quickly becomes a morass.