PROJECT PLANNING FOR PRODUCT DEVELOPMENT

WHAT ARE THE DIFFERENCES AND SCOPES IN PROJECT PLANNING

METHODOLOGIES?

A SEMINAR PAPER SUBMITTED FOR THE COURSE “CURRENT ISSUES IN ENGINEERING

MANAGEMENT” TO THE INTERNATIONAL UNIVERSITY OF APPLIED SCIENCES,
ERFURT, GERMANY.

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTERS OF

ENGINEERING, ENGINEERING MANAGEMENT (M.Eng.)

By SUNNY NWACHUKWU

(Matriculation Number:9212650) 2023/2024

NOVEMBER 2023
Contents
1.0 Background ............................................................................................................................................. 3
2.0 Introduction to Project Management Methodologies ................................................................... 3
2.1 Some Specialized Project Management Methodologies ......................................................... 3
3.0 Project Planning ..................................................................................................................................... 5
4.0 Adaptations of Project Planning for Product Development ....................................................... 7
4.01 Waterfall Project Planning............................................................................................................. 7
4.02 Agile / Scrum Projects Planning. ................................................................................................. 8
4.03 Extreme Programming: ................................................................................................................ 10
4.04 Lean Project Planning: ................................................................................................................. 10
4.05 Critical Chain Project Management: ......................................................................................... 12
4.06 Rational Unified Process (RUP) ................................................................................................. 13
4.07 Feature Driven Development [FDD] .......................................................................................... 14
4.08 Crystal Methods ............................................................................................................................. 14
4.09 Joint Application Development .................................................................................................. 16
4.10 Adaptive Project Management ................................................................................................... 17
5.0 Conclusion............................................................................................................................................. 19
6.0 REFERENCES ....................................................................................................................................... 21

2
1.0 Background

We live in unprecedented times, and the speed of changes fueled by technological advancement is
daunting. We can evaluate these changes from the VUCA perspective or the “the world is flat”
perspective. This evolution has necessitated the application of project management in almost all
endeavours.

This research paper sets out to evaluate different project management tools and methodologies,
with a specific focus on how the different methodologies are suited to specific scopes and scenarios.
Project management has evolved from the days of only sticking up notes and Excel sheets to highly
intuitive adaptations and tools in response to the changes in the spheres of application. With the
entrance of pervasive mobility and artificial intelligence, the frameworks deployed to deliver projects
need to evolve to reflect the scope of the project, its business case, and the peculiarities of the team
that delivers it.

2.0 Introduction to Project Management Methodologies

There are quite a few definitions of what a project is, and these generally depend on the body of
knowledge being referenced. The Project Management Institute’s PMBOK (widely popular in the
USA and North America) defines a project as “temporary efforts to create value through unique
products, services, and processes,” while project management is “the use of specific knowledge,
skills, tools, and techniques to deliver something of value to people. The development of software
for an improved business process, the construction of a building, the relief effort after a natural
disaster, and the expansion of sales into a new geographic market—are all examples of projects.

PRINCE2 is another popular methodology (it is the standard for the United Kingdom government),
and it is an acronym for “Project in a Controlled Environment.” It defines project management as a
process-based approach that focuses on organisation and control throughout the entire project; it is
not particularly suited for small projects.

2.1 Some Specialized Project Management Methodologies

Apart from the two mentioned above, there are other iterations that are suited for specific situations.
I will briefly highlight a few below and subsequently go into more detail in the following chapter

Waterfall Methodology: This is the most traditional and straight-forward application of project
management principles and is widely used in construction and parts of the telecommunications
industry. It is best suited for projects that are not likely to experience huge changes during their
execution. It is the most sequential of the methodologies; a straight-forward transition from one stage
of the project to another with very limited iterations, and it is not very strong at dealing with very
3
strong change (and change management) requests. Excel sheets and Gant charts are typical tools
used.

Agile Methodology: This is best suited to the fast-paced, dynamic, collaborative, and iterative
nature of software development. Planning continues even as execution is ongoing. All the stages
and stakeholders may still be live for the duration of the project. The agility of this methodology
speaks directly to the uncertainty and ambiguity in “VUCA”. Other industries where this methodology
has been used include innovation and marketing.

Scrum Methodology: This is another framework that is best suited for software development (or
any other application that needs flexibility with many moving parts). It is usually used within the agile
framework and is based on creating short time windows for project management within the ever-
evolving broader agile framework. It focused on a small number of team members (typically 10 or
fewer) and short time windows (typically 2 weeks), with the use of daily scrum meetings to align team
members and deliverables.

Critical Path Method/Critical Chain Project Management: This is a subset of project management
using PMBOK guidance and prescribes decomposing the project into tasks and activities (work
breakdown structure) and assigning an estimated duration to each task. A network diagram is based
on the duration of each task and their interdependence; the longest sequence of tasks will define the
project duration and is called the critical path. This methodology is used when the project schedule
is very important; tasks on the critical paths are monitored to ensure that any changes do not
adversely impact their duration since they will have a consequent impact on the duration of the
projects. It is best used for small projects or intermediate stages of a project because the more tasks
that have to be factored into the critical path, the more complex it gets and the more impactful errors
in duration estimation will be. Critical Chain Project Management: This also takes guidance from the
PMBOK and puts a premium on having a nimble and agile balancing of the resources (man, material,
and machine) needed to deliver a project and less emphasis on project duration. It can be
incorporated into any project that has a strong resource or cost constraint.

Kanban Methodology: Kanban translates to billboard in Japanese. It prioritises the visual planning
and tracking of projects using what is called a “Kanban Board”, It helps for a common view of tasks,
activities, and the project as a whole. The Kanban methodology is a subset of the lean/Six Sigma
philosophy for project and process management; it aligns easily with agile project management in
software development. Many mobile project management tools (Trello, Asana, Basecamp,
Workzone, Wrike, Sorted, Monday, Click-Up, Pipefy, Taiga, etc.) are, by extension, dynamic Kanban
boards. They can also be put to a variety of other uses in software development, marketing, and
strategy planning.

4
Extreme Programming: This is truly a 4.0 software development project management methodology
that incorporates the long tail principle. It is a subset of the agile software development methodology
that uses short development circles, multiple releases, and inputs for customers to dynamically keep
adapting to the project while improving productivity. It is particularly useful when customer
requirements are continually redefined and the demand for a higher quality of service is ever-
evolving.

Lean Methodology: Just like its name implies, it is a project management methodology that strives
to use waste reduction strategies and tools to increase the net useful value of the project. It focuses
on tasks, processes, and activities and looks for ways to eliminate waste from their value streams.
In the competitive, cutthroat software development space of the post-Covid era, teams are focused
on user experience by running lean processes. It has a strong use case in manufacturing and
construction, but it has also found strong relevance in software development and new product
development.

Six Sigma: This methodology is focused on increasing quality by identifying what is working, why it
is working, and how it can be made to work in its best state and maintain that state while committing
to continuous improvements. This quality management is achieved through painstaking empirical
statistics. It is sometimes bundled with lean project management. It works best in large organisations
and needs the commitment of senior leadership.

We also have a number of other methodologies that are focused on software development they
include the following
 Rational Unified Process (RUP)
 Feature Driven Development [FDD]
 Crystal Methods
 Joint Application Development (JAD)
 Extreme Programming (XP)
 Adaptive Project Management

The scope of this write-up will not allow the exhaustive discussion of all these methodologies but an
effort will be put towards an overview.

3.0 Project Planning

Project management has a variety of phases, and depending on your reference, it might be as little
as 3 or as many as 7, depending on the literature being reviewed. And the industry being a reference,

5
we will start by looking at traditional project planning using the PMBOK and, from there, reviewing
project planning for other methodologies.

According to Project Management Institute, Inc., A Guide to the Project Management Body of
Knowledge (PMBOK Guide), 4th ed. (Newtown Square, PA: Project Management Institute, Inc.,
2008), 11–16, the main phases are Initiation, Planning, Execution, and Close Out.

We also have another school of thought listing the stages as Intake Lifecycle, Initiation, Planning,
Product Selection, Execution (Implementations), Monitoring and Control, and Close Out.

Another source lists the stages as

 Project Initiation and Strategy Development

 Project Design and Planning
 Execution and testing
 Project Launch and Training
 Support Launching
 Closing

One of the common denominators in all these breakdowns of the phases of project management is
planning. While all the stages are critical, this write-up is focused on project planning for product
development.

A product is any uniquely identified item that has been specifically offered to satisfy a need and is
made at a cost. The need may be private, public, or posterity-related. It may be an article, a structure,
or a service. A product has a useful lifecycle and must be designed and planned to not just meet
expectations but also meet them for its projected useful life.

Planning is the stage after initiation when a decision has been made to go ahead with the project. It
involves decomposing the project into smaller activity work packages, defining objectives as well as
the deliverables that will define their attainment with specific metrics. During the planning stage, the
resources (human and material) the project will need are estimated, and projections on how to
source them are also laid out. Scheduling and risk assessment also take place at this stage.

Since projects, by their very definition, are unique, their plans will be unique as well, a function of the
industry, scope, and constraints being focused on. The project is the reference or baseline document
for the project and will be updated in response to changes that may become necessary as the project
progresses. It is the thread that defines the interdependence of the various facets of the project, and
as such, it is being constantly updated throughout the life of the project. The product of the planning
stage is the project management plan.

6
The plan is made up of a compilation of documents that focus on different aspects of the project.
They are designed to manage the three key constraints of all projects, which are scope, schedule,
and budget.

The key steps for most projects are as follows:

1. Exhaustively identify stakeholders.

2. Clearly assign roles to team members and stakeholders.
3. Communicate the vision of the projects to team members to galvanise alignment.
4. Set goals and break these goals into deliverables (we sometimes have intermediate
deliverables).
5. Prioritise tasks based on the three constraints (scope, schedule, and budget). A useful tool
for this is a Gant chart because it shows the duration and interdependency of tasks.
6. Identifying the critical path by creating a schedule will also help in scarce resource allocation.
7. Carry out a risk assessment and craft a risk management plan.
8. Develop a communication plan to ensure that relevant stakeholders are kept abreast of
progress (or lack thereof) in a manner that prevents avoidable conflicts.
9. Develop a change management plan; this deals with how changes are incorporated into the
project.
10. Finally, have a plan for reviewing the plan.

If these steps are effectively and efficiently followed, the document generated will

1. Create a common reference for all stakeholders.

2. Mitigate conflicts that may arise due to possible ambiguities.
3. Act as an input tool for all activities designed for the monitoring and control of the project.
4. The updated document at the end of the project will detail lessons learned and, as such, can
be a teaching tool for future projects in that organisation.

4.0 Adaptations of Project Planning for Product Development

4.01 Waterfall Project Planning.

This is the most linear of all the project management methodologies. It is typically used in
construction and manufacturing projects, which by their very nature work well with clearly defined
sequences (you cannot revisit the foundation after the wall is in place). They also have requirements
and expectations defined before the project begins. The project is split into deliberately discrete

7
phases, which are executed sequentially in an “end to begin” pattern. Any review has to go back to
the first phase and have the whole process repeated.

It requires a very clear definition of requirements, a thorough design and design review process, and
a clear, unambiguous assignment of roles.

The typical phases are as follows:

1. Requirement Definition
2. Design
3. Implementation
4. Testing
5. Verification or closure
6. Maintenance

In this methodology, the planning phase is critical because the planning document is almost cast in
stone and is not subject to changes, as such a huge importance is placed on documentation. Some
of the documents may include standard operating procedures and method statements; these
become particularly useful when tracing challenges or onboarding new team members. The
principles of waterfall project management are the foundation for other methodologies and can find
application in some aspects of all organisations.

The main challenge with this methodology is the difficulty that may be faced if a major change needs
to be implemented after the testing stage. It is best suited to short projects with non-changing,
explicitly defined requirements and expectations from the beginning and limited interdependence on
other projects. It is generally the easiest to track and manage. Some tools used are mind maps, user
flow diagrams, and workflow diagrams.

4.02 Agile / Scrum Projects Planning.

This is an iterative, incremental project management methodology that has become very popular
because it is best suited to the “VUCA” world of today. The focus is on moving user requirements
rather than fixed technical specifications. The methodology is designed for continuous requirement
definition and changes throughout the lifecycle of the project. (Some of these changes may be due
to input from users or a new technological breakthrough.) Scrum is a subset of Agile, and since they
have many overlaps, we will therefore take them together.

During the planning stage, time windows are agreed upon where team members from various
functions work on the product iteratively, keeping the targeted objectives and key results (OKR) in

8
clear perspective. The work done in each time window is organised into backlogs. Each iteration has
the primary objective of delivering a working project.

With Scrum, there is plenty of room for changes in response to further clarity on user requirements
or changing market conditions. Scrum uses a concept called sprints to breakdown the project into
iterative time windows (typically two weeks) in a bid to take care of new inputs or requirements (fixes,
updates, new features, new regulations, etc.) through incremental improvements. A predetermined
number of items (user stories) to deal with in each sprint is agreed upon. Each sprint is further divided
into ceremonies where team members plan the following: plan the next sprint and what to
accomplish; align team members and hear out concerns; and review the demo at the end of the
ceremony to identify opportunities for improvement.

The stages in agile planning are as follows:

1. Define the relationship between user needs, features, and project goals.
2. Detailed decomposition of features, clearly capturing risks and dependencies
3. Using the historical pace of teams, practically estimate the amount of work and assign it to
teams and sprints.

For the Scrum planning process, we have the following steps:

1. Retrospective meetings are held to review and identify takeaways from previous sprints.
2. Conduct a sprint planning meeting to review and update the release plan, incorporating new
features, requirements, and insights (on the project, product, and team).
3. Ensure user stories are detailed enough to limit assumptions and ambiguities down the line.
4. Decompose user stories into specific tasks and assign tasks to teams or team members (and
get their buy-in).
5. Use stick-up notes to visualise all user stories and tasks (on this sprint) on a board for all
team members.
6. Using a grid that details tasks, responsible members, projected duration, and progress, track
the entire progress of the sprint and project. (Team members make inputs on the board that
are visible to all team members.)
7. With a burndown chart, compare the project schedule progress vis-à-vis the project progress.

Also important are the daily stand-up meetings during the sprint, which are done to quickly and briefly
bring everyone up to speed and highlight challenges and risks. The scrum master coordinates these
meetings and provides guidance for dealing with challenges or bringing the project back on course.
Many agile/scrum projects and teams are managed using work operating software (Work OS).

9
4.03 Extreme Programming:

This can be considered a subset of agile project management that is used only for software
development. It is focused on increasing the productivity of coders and seeks to promote effective
and efficient coding collaboration between software developers. XP is iterative like Scrum but is not
as liberal; the code and the coders are its core concerns as opposed to the larger team dynamics
that are found in Scrum.

The XP-prescribed steps to make software development easy are

1. Coding: The code must fulfill the customer's needs.

2. Testing: This validates that the need has been met.
3. Listening: This is when the requirements of the customer and the process are gathered.
4. Designing: This is when the voice of the programme is listened to and input is made into the
development.

The project lifecycle in XP involves a very specific and deliberate process.

Small Releases: Weekly Cycle; Quarterly Cycle

The customer is given the completed work as “small releases” at each week’s end. The deliverables
in the form of features are to be delivered to the client at the end of each week. This is planned and
decided during the “weekly circle”, Multiple weekly circles may be used for more complex and time-
consuming features. Quarterly cycles tie all the efforts together to ensure the strategic targets of the
effort are met.

Terms used in XP include

Pair programming, collective code ownership, Together but alone, cross-functional teams, customer-
always-available, information radiators (via Kanban board).

4.04 Lean Project Planning:

This methodology can be applied at each phase of the project management process for other
methodologies. It offers a review of the phase to ensure that waste is limited and the best net value
is delivered to the project, the product, and the user (amongst other stakeholders). It combines the
adaptive principle of executing (with what is known) while testing and validating (for what may be
unfolding). This produces an adaptive, risk-resilient project and product. Examples of unfolding
issues may include customer feedback, new technologies, the project environment, actual project
team productivity, price changes, and market changes, to name a few.

10
For lean project planning to succeed, some conditions need to be in place.

1. A shared understanding of expectations, risks, and definitions of what constitutes waste from
all stakeholders
2. a robust, harmonious communication system to carry all parties along (particularly during
adaptation).

Lean project planning is anchored on the following principles:

1. To create understandings and agreements between project stakeholders, the evolving

network of agreements (NOA) and how to manage them is the ultimate project plan. The
agreements may be formal or informal, conscious or implied.
2. All project plans should be developed into agreements that acknowledge and detail potential
risks, assumptions, and unknowns. For this to work, planning needs to be based on
collaboration and consensus while being decentralised to ensure that input is coming from
people on the front lines of the work flow. This is called push-and-pull planning.
3. Agreements need to be based on trust and open relationships and must be designed to
deepen trust.
4. Planning has to be adaptive and continuous, with continuous improvement in mind.

The key steps may include the following concepts:

 Identify value by defining requirements and stating expectations.

 Map the value stream by identifying all steps in the project; this is the value stream. Draw a
value stream map.
 Create continuous flow, identify potential bottlenecks in the flow of the project, and eliminate
them.
 Establish a pull system and ensure resources are there just when they are needed.
 Seek perfection through iterative, continuous improvement.

Some tools that are typically used include

 The Deming Cycle (Plan, Do, Check, and Act)

 Lean Six Sigma Principle (Define: Measure, Analyse, Improve, and Control) or (Define:
Measure, Explore, Develop, and Implement)
 Pareto Charts

Lean defines waste as any process or item that does not have a net positive impact on the project
or the final product. The seven types of waste are

11
 1. It goes against the principle of “just in time” and creates unnecessary storage costs.
2. Due to inefficient scheduling, resources are kept idle.
3. Defects result in reworks, with their attendant impact on schedule and cost.
4. Overproduction
5. Motion
6. Transportation
7. Over-processing

4.05 Critical Chain Project Management:

This uses the terms and guidance implied in the PMBOK. Its application is after the schedule of the
project has been hashed out, such that dependencies of tasks and subtasks have been worked out
and a critical path has been found. Each task is then re-evaluated using the theory of constraints;
this may result in a revision of the critical path.

The uncertainties on tasks are tied to overestimations of the duration and resources needed to
execute a task in a bid to allow for margins of error. These margins compound and stretch the
duration and cost of the project and may affect interdependencies, especially when tasks are
completed well ahead of the estimated.

There are 3 types of buffers used in critical path project management:

Project Buffer, Feeding Buffer, and Resource Buffer

The project buffer is an additional time margin added to the last task to ensure that even if the task
is delayed, it does not affect the total project duration. Early completion of tasks will increase the
project buffer, which reduces the uncertainties on a project. Feeding buffers protect the critical chain
from challenges in the feeder chain (the feeder chain is a path of activities that close out on the
critical chain); they are placed in the last activity on the feeding chain (compared to the project buffer
that is placed on the last activity on the critical chain). Finally, resource buffers may be man, material,
or machine and are positioned and provisioned to ensure that they are available without delay when
needed. They are focused on timely critical resource availability to protect the critical chain.

It has found application in manufacturing but has not fared well in IT due to complex critical paths
and difficulty in estimating task duration in the fast-paced world of IT. It is, however, a good tool for
project risk assessment.

12
4.06 Rational Unified Process (RUP)

It is described as an “object-oriented” software development process. It asserts that

The scope of a project cannot be fully defined at the onset because the requirements for defining
product and project success may evolve as the software development process progresses.

Risk assessments should be carried out early in the project. This should highlight the high potential
and high impact risks and have them mitigated or avoided early.

To ensure that the product meets acceptable quality standards at optimal costs, testing and quality
assurance activities should be continuous during the development process.

Just like all software development-focused processes, it is iterative, which helps in incorporating new
requirements as well as managing risks.

Management as well as technical leaders should have a perspective on the software development
process (and not only coders).

The RUP process is made up of a gated, four-phase development lifecycle.

Inception, Elaboration, Construction, and Transition

At the inception phase, the priority is on the specific scope of the project and how it will guide the
development of the business case. It also encapsulates risk assessment as it may affect the project
requirements. An appropriate software architecture (which is a major risk item) is identified among
the alternatives, and a software development plan is developed during the elaboration phase. The
construction phase involves developing further details around the selected architecture while
developing the solution. The output of this stage is the iteration plan, which captures the iteration
schedule, costs, and manpower needs. The transition phase covers all activities that lead up to when
the solution is installed in the user’s specific context; it may include sales, marketing, training, rollout,
etc. Iterations to deal with issues that may arise at this stage are still done until the user signs off,
after which any further revisions are termed product maintenance.

Decisions about the continued funding of an RUP project are taken during the gates along the
lifecycle of the project (typically as each phase comes to a close). In RUP, this decision cycle is
called a milestone, which is a “point in time at which certain critical decisions must be made and
therefore key goals must have been achieved” (Kruchten, 1996). In RUP, the business case is
defined by acceptance of the scope and requirements, and consequently, the solution or product is
the ultimate focus.

13
4.07 Feature Driven Development [FDD]

This is another software-focused agile project management methodology that is focused on the
iterative and incremental development of the software features (much like user stories in scrum
project management). It ensures that the software being used by the client is up-to-date and working.
This is achieved by ensuring that its iterative cycles are short and based on feedback from the end-
user.

Its life cycle is as below:

Build the overall model - Build the feature list- plan by feature- Design by feature - Build by
feature.

The main domain model is built while the bulk of the time is spent designing and building the feature
list that has been developed (this list may be increased based on feedback from the user). The
release and update of features are continuous processes.

The reporting practices of FDD ease the tracking of the progress of the project (particularly
continuous success) while reducing risks that may arise. They also help in budgeting for the project
since the project is broken down by features. However, the methodology is cumbersome for smaller
projects and teams and has an overdependence on the lead programmers who developed the main
domain.

4.08 Crystal Methods

This is another agile-linked software development, object-oriented project management

methodology that is focused on people (their skills and talents) and their inclusive interaction
(communication). It has the reputation of being lightweight and flexible, making use of many agile
processes. It posits that individual projects have inherently unique characteristics, and policies and
processes to drive them need to be customised to accommodate peculiarities, and teams need to
streamline their work to suit the specific project (its team size, criticality, and priority).

Some of its properties are crystal properties.

Teamwork, communication, simplicity, reflection (responding, reporting, reasoning, and

reconstruction), frequent adjustments, and continuous improvement

Crystal teams are categorised using colours based on their size and a combination of factors such
as comfort, discretionary money, essential money, and the life of the project. On the other hand,
structure and objectives are also considered. The families are

14
 1. Crystal Clear (only one team on a project)
2. Crystal Yellow
3. Crystal Orange
4. Crystal Orange Web
5. Crystal Red
6. Crystal Maroon
7. Crystal Diamond and Crystal Sapphire (incredibly significant, potential risk to human life)

The Crystal Methodology has clearly defined roles (an assignment may cover many roles).

The Leading Roles Sub Roles

Executive Sponsor: Project Coordinator (Actual Project Manager)

Executive Business Expert

Lead Designer Technical writer

The Ambassador User Business Tester

The properties of the Crystal methodology vary from family to family, but those for Crystal Clear are
as follows:

1. Frequent Delivery: Each release should put out working software according to user
standards.
2. Reflection Improvement: continuous discussion amongst team members on what will and
won’t work.
3. Osmotic Communication: Discussion when all team members are present should be regular.
4. Personal Safety: Empower team members to speak about concerns without fear of retribution
or harassment.
5. Focus: Leaders must set out clear priorities and allot time and resources for teams to achieve
them.
6. Easy Access to Expert Users: Typical end-users must be easily available to evaluate the
output product.
7. Technical Environment: This enabled the continuous testing of the product and parts of the
product.
8. Frequent Integration: Since various teams are iterating, the more frequent the integration,
the better.

The process lifecycle of the Crystal Methodology

15
The Project Cycle – The Delivery Cycle – The Iteration Cycle – Integration Period – The Episode
Chartering Activity Daily Stand Up
Cyclic Delivery
Wrap-up

The Crystal Methodology is flexible, adaptable and prioritises the critical and essential components
of the project with small or large teams, encouraging effective team engagement in a fixed-price
atmosphere. However, the variation of principles with team sizes and, the need for constant team
engagement presents a downside, particularly for distributed teams. The fact that planning is
disconnected from project requirements is also a challenge when major changes may need to be
made in the middle of the project.

4.09 Joint Application Development

Joint Application Development, or JAD, as the name implies, is based on client and end-user
involvement in a bid to develop ideal solutions. It uses a tool called “JAD Sessions” successively as
a tool to collaboratively and speedily refine specifications and requirements based on user input and
business needs. JAD sessions involve a variety of stakeholders and may last from as little as an
hour to days.

The objectives of JAD sessions are to simplify and define the work and its needs and specifications,
identify issues and participants in the project, and Quantify all the data and needs needed to deliver
the project. Clarify and agree on all criteria and assumptions. Unify all the phases and stages of the
project towards a common goal, and finally, satisfy end-users by getting them to thoroughly
participate in the success of the project.

The main roles are:

1. The executive sponsor, probably a CIO, CEO, or CISO, champions and visions the project
and is the final decision-making authority on the project.
2. The facilitator, who plans all the JAD activities (schedules, organisation, conflict resolution,
etc.) such that there is balance, collaboration, and synergy with end-users,
3. The IT Representatives are the developers on the team who deliver technical models and
build prototypes by translating customer needs into models that can be put on the market.
4. The end-user is the main focus of the JAD methodology. They are the object and source of
the strategy, tactical plan, and business plan, while also contributing strongly to defining
requirements.
16
 5. The Scribe provides and acts as a reference by effectively documenting JAD processes and
sessions.
6. The observer acts as a reviewer. They evaluate each JAD session to confirm that choices
achieve end-user needs. This review takes place at the end of each session.

Just like all other methodologies, the JAD process is phased as follows:

Define objectives: session preparation, session conduct, and documentation.

During the “define objectives” phase, the meeting programme and deliverables are put together by
the facilitator and distributed to attendees for their input. This gives way to the “session preparation”
phase, where the facilitator now drills down on the programme and deliverables and makes provision
for them. Next is the JAD session proper phase (session nduct), where the session takes place and
the project is evaluated. First releases and prototypes may be brought out for comments,
clarifications, and concern resolution by stakeholders. The final stage is the “documentation” phase,
where all the design, specifications, and requirements are put together and reviewed.

JAD sessions have clearly spelled out objectives and are executed in the presence of the right
technical and business team members. The engagements during JADs are guided by questionnaires
and agendas, while clear delegation of tasks and deliverables is delegated. The objective is to spur
innovative thinking that is shared and discussed with experts from other departments; it has to be
an inclusive team effort between customers and IT representatives as such, development time is
reduced and customer satisfaction improved.

With JAD, there may be intra-team conflicts that hinder the alignment of goals. The size of the project
projects determines the time spent on JAD by stakeholders, as they may become quite substantial
as the size increases, so it may not be ideal for all projects and organisations, but it inclusively brings
MIS and users together in a constructive and structured setting to reach consensus-based
requirements and specifications.

4.10 Adaptive Project Management

This project management framework is structured and systematic and best suited for fluid projects
and organisations. Plans and project elements are flexible by default to compensate for fluctuations
in the project, its requirements, and its operating environment. It relies on short decision circles that
are dependent on the most recent output of a phase or stage. Adaptive Project Management
Framework (APF) has three main cardinal drivers: it thrives on change, learning is by discovery, and

17
it is client-driven. This is why it is used by a variety of firms for their large projects, particularly
software and environmental projects.

The stages of APF are as follows:

Planning, Execution, Monitoring, Controls, and Evaluation

The phases may also be defined as

Client Check
Project Scope Cycle Plan Cycle Build Final Review
Point

Project scope is the stage where stakeholders engage and define what their expectations are from
the project and its product. Boundaries for success are clearly spelled out. Deliverables at this stage
include the Conditions of Service (CoS), detailed by a Project Overview Statement (POS), a work
breakdown structure (steps in chronological order), and a scope triangle (that shows the balance
between project schedule, cost, and scope). During the cycle plan, the project is broken down into
bit-size iterations, assigned to teams, and specified with deadlines and sequences, as well as how
the iteration teams running them interact. The WBS may be a key input to the cycle plan. The cycle
build stage is when the plan developed in earlier stages is put into play and also where the most
lessons are learned and changes implemented (either in response to the client’s requirements or
changing business and operational environments). The client checkpoint is the point of practical
completion where the client evaluates the product of the project; any feedback is subsequently
implemented to provide a final product. The process continues until the customer is satisfied (within
the budgetary provision of the project). This is a stock-taking phase by the project manager, team,
and stakeholders to evaluate the project compared to the original plan and measure success. It may
also be an opportunity to document lessons learned.

APF may be active or passive. Passive APF allows the application of lessons gleaned from earlier
stages or iterations in managing the current stage of the project. By doing so, risks are reduced.
Active APF allows for the execution of possible project scenarios (as experiments) to gather lessons
that will drive the project management strategy to be applied. Active APF prescribes that project
strategy be defined early and made flexible (even accommodating reversal of decision if it becomes
imperative) and that the project plan be divided into many iterations. This methodology also
acknowledges the potential impacts of risks and demands that, apart from a detailed plan with a
schedule, all risks for the next phase should be identified using a quantitative risk analysis (and
consequently, a mitigation plan).

18
The main distinguishing factor of APF compared to waterfall or agile is its use of quantitative risk
analysis to evaluate models, rate actual project progress, and manage risk.

The core values of APF are as follows:

1. It is client-focused; the client’s ethical needs define project success.

2. It is client-driven; clients are involved in decision-making from the beginning and as
incremental progress is made.
3. It dwells on continuous questioning and introspection; and open, continuous engagement by
clients and team members to ensure continuous improvement and the best results.
4. Change is the progress towards a better solution; outputs from the early stages of the project
will guide the team in the best direction to steer the project and its deliverables.
5. Don’t speculate on the future. No guesswork and no non-value-adding work.

5.0 Conclusion

The need to understand the different, available project planning methodologies and their relevant
scope can not be understated. Today's world, where we live and work, is undergoing a really fast
expansion in knowledge and change. The rate at which knowledge and data are being gathered is
only being matched by the increasing capacity to analyse and extract useful information from that
data. New products, new methods of doing things, and ongoing disruptions are the results of this.
The lifecycle of norms is becoming increasingly short.

The means by which insights and discoveries are turned into innovations and products—which could
include buildings, services, or software—are projects. Much effort has been (and continues to be)
put into gathering, analysing, and organising lessons gained into frameworks and methodologies.
We frequently have projects inside projects, which is a challenge because of their simultaneous
diversity and originality.

The days of using project management as a recipe book with set procedures and templates are long
gone, especially for projects where constant change is a factor. Today's business and product
development worlds view project management as a toolbox; different tools, or combinations of tools,
are used to address particular project types (or subprojects), their requirements, and their clients;
occasionally, new tools must be

To plan a project in these VUCA times, the project manager must not just be familiar with the tools
and how to put them to use but also be aware that there may be a need to create new tools or
adaptations and combinations of existing tools (methodologies) to deliver on the mandate of being

19
a project manager. It starts with having an open mind to appreciate when to use what and when
there needs to be a mix of tools. To achieve this, a clear understanding of the project is necessary,
as is clarity on the strengths and weaknesses of each framework in planning a project.

Planning a project to deliver a typical product today will include planning for the hardware and
software aspects of the product as well as the physical operational space; all of these may be run
by the same planning team. With each subproduct being interdependent on another, different
methods will be put into play to get the best out of the whole project by getting the best out of each
deliverable using systems thinking methods.

Many times, the project management methodologies listed above are as different as they could be
complementary. In essence, the project is a vehicle for realising innovation and delivering the
infrastructure that the innovation will ride on. It has to accommodate new requirements such as
sustainability (social, financial, and environmental), which is now a deal-breaker, while being robust
enough to adopt technological changes such as those that AI presents that may impact its lifecycle.

All these factors will impact the reoccurring triple constraints that impact all methodologies: schedule,
cost, and scope, while adding new gatekeepers such as interdisciplinary competencies (to meet the
complexities of evolving technologies) and new regulatory environments.

Professionals who are involved in not just planning projects but also product development must be
aware of tested and mature methods for planning different types of projects. This will have a huge
impact on reducing product development time and cost while encouraging innovation.

20
6.0 REFERENCES
Project Management Institute, Inc. (2023). What is Project Management?
https://www.pmi.org/about/learn-about-pmi/what-is-project-management

Wrike, Inc (2023). What Is PRINCE2 Project Management? https://www.wrike.com/project-management-

guide/faq/what-is-prince2-project-management/.

Kinsta Inc (2023). The 18 Best Trello Alternatives (Features, Price, UI Compared).
https://kinsta.com/blog/trello-alternative/

Aleksandar Olic (2017, Sep). Extreme Programming (XP). https://activecollab.com/blog/project-

management/extreme-programming-
xp#:~:text=Extreme%20Programming%20(XP)%20is%20an,way%20to%20collaborate%20on%20cod
e.

Bennett, Coleman & Co. Ltd (2023). What is 'Product?

https://economictimes.indiatimes.com/definition/product

Lucid Software Inc. (2023). What the waterfall project management methodology can (and can’t) do for
you. https://www.lucidchart.com/blog/waterfall-project-management-methodology

Rebeccas Wojno. (2022 Feb). Agile planning a step-by-step guide and template.
https://monday.com/blog/project-management/agile-planning/

Eshna Verma (2023, April). What is critical chain project management? https://www.simplilearn.com/what-
is-critical-chain-project-management-rar68-article

Sudarsan Reddy. (2019, February). Critical Chain Project Management Methodology and Buffers Explained?
https://medium.com/@sudarhtc/critical-chain-project-management-methodology-and-buffers-
explained-4caf3f0a2a2

Lambertsen, L. (2002). Project management in a rational unified process (RUP) environment. Paper
presented at Project Management Institute Annual Seminars & Symposium, San Antonio, TX.
Newtown Square, PA: Project Management Institute.

ProductPlan. (2023). Feature Driven Development (FDD). https://www.productplan.com/glossary/feature-

driven-development/

Utkarsh_Kumar (2023, April). FDD Full Form. https://www.geeksforgeeks.org/fdd-full-form/

ProductPlan. (2023). Crystal Agile Framework. https://www.productplan.com/glossary/crystal-agile-

framework/

Fegno Technologies LLP. (2023). What Is Joint Application Development (JAD)?

https://www.fegno.com/what-is-joint-application-development-jad/

Zarmeen Zehra. (2023). What is Joint Application Development (JAD)?

https://www.educative.io/answers/what-is-joint-application-development-jad

21
Maja Mrsic(2021, July). Adaptive Project Management. https://activecollab.com/blog/project-
management/adaptive-project-management

Indeed. (2023) What Is the Adaptive Project Framework? (A Definitive Guide).

https://www.indeed.com/career-advice/career-development/adaptive-project-framework

Antonio Nieto-Rodriguez, Ricardo Viana Vargas. (2023, October).The Opportunities at the Intersection of AI,
Sustainability, and Project Management. https://hbr.org/2023/10/the-opportunities-at-the-
intersection-of-ai-sustainability-and-project-management

Lean Project Management Foundation. (2023). Chapter 9: Lean Project Planning. https://leanpm.org/lean-
project-planning/

Moujib, A. (2007). Lean Project Management. Paper presented at PMI® Global Congress 2007—EMEA,
Budapest, Hungary. Newtown Square, PA: Project Management Institute.

Simplilearn.(2023). What is Lean Project Management? Understanding the 5 Principles.

https://www.simplilearn.com/what-is-lean-project-management-article

22