In some projects there are some misunderstanding about what is the best way to manage the project or to differ between the projects that have in some parts clear product scope and the other part not well defined scope . Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The key thing is to understand that you are creating a solution where solution is equal to "the thing" (product/service/result) to be created plus "the way" (project) to create it. Both are defined before a project exists, before a business case or similar is created, and business analyst is accountable for that with the help of somebody that has knowledge about project manager (then, she/he could or not could be the assigned project manager when the project is created). So, the selection of "the process" is critical and to do that you have to take into account first of all "the thing" to be created the current situation. Just with the aim to help here comes an article I created time ago about the matter https://www.projectmanagement.com/blog-pos...right-solution. Just an example from my personal experience: I was part of one of the well known and today most used browser in the market (the leader in market share terms). Those that used it from the begining pehaps remember that for long time the word "beta" was under the name. That´s because due to the uncertainty about the browser acceptation from the people the product was released by increments, we learn from people feedback, and in the next release all we learned was included in the new version and the feedback loop started again So, if you have a product where you have core requirements well known but you do not have a way to get and validate "peripherical" requirements then iterative-incremental life cycle applies. Saving Changes...
The situation you are describing would lend itself to rolling wave planning. That can be still be done with a deterministic delivery approach where you plan what you need to deliver in the near term to a low level of detail and then plan subsequent phases as you get closer to the time when they will be executed.
If you are in a situation where within the same time frame some work streams lend themselves to deterministic delivery and others to adaptive, then you are looking at hybrid delivery approach.
- What type of work is being performed? Can it be split into smaller pieces that deliver value sooner than the whole?
- How flexible is your organization? Does leadership place mandates on how work should be performed, in addition to what needs to be delivered? Is it structured to support multiple approaches to performing and reporting on product delivery?
- How experienced and flexible are your people? Do they have the required training? Can they be dedicated to one project or are they expected to work on many projects?
- How distributed is your team? Can they be collocated? If not, are there collaboration tools available, that they are familiar with? Does everyone share the same expectations for how and when to collaborate?
- How much ambiguity can your company handle? Does leadership have to know how long the project will take and how much it will cost before the project can start?
There's more, but the point is to understand your people, leadership, environment/culture, and work in order to determine the best way to manage a project. Depending upon the type of company you work for, understanding your customers may also be an important consideration. Saving Changes...
One of the critical factors that determine the solution approach to a project is the impact of change. This varies widely by the type of project.
Depending on the underlying product, the nature of the change, and the processes used to create the product, changes may be easy to incorporate at virtually any time, or virtually impossible to change once a decision is made.
For some types of products, there may be components with very long lead times, design processes that are very time consuming and expensive, or other factors that can make later changes cost prohibitive or even impossible later. Once you've poured the foundation of a building, it is difficult to move. These types of factors drive a more predictive approach.
Other types of projects may be very modular in nature with few dependencies outside of nicely contained work packages. These may provide far more flexibility as to when decisions must be made.
Factors like how long it takes for changes to be incorporated into a product, the cost to make changes to various elements of the product, and the interdependencies between various elements of the project may be very important to understanding the suitability of various lifecycle models. Saving Changes...
Community Champion
