Project Management Methodology

Quick reference

• 00:04 Hi, I'm Ray Sheen.
• 00:05 Let's talk about project management methodologies.
• 00:08 This will prepare us for an assessment of the strengths and
• 00:12 the limitations of these various methodologies.
• 00:15 So what are the elements of a project management methodology?
• 00:18 Well, I'll start by acknowledging that it is a standard process.
• 00:22 It is meant to improve communication and execution by ensuring that people
• 00:26 start doing the project activities in the same manner again and again.
• 00:30 The learning curve effect will improve the quality and efficiency.
• 00:34 This is usually documented through some procedures, templates, and checklists.
• 00:39 But most organizations realize that every project is unique, so
• 00:42 they allow some level of customization within the methodology to accommodate
• 00:47 the project uniqueness.
• 00:48 There ill often be variants for the size or
• 00:51 complexity of a project in addition to variants for different types of projects,
• 00:56 such as software projects, facility projects, or cost reduction projects.
• 01:01 A project approach becomes a methodology when everyone in the organization begins
• 01:06 to use it.
• 01:06 I know of several occasions where a wonderful new process and
• 01:10 checklists were issued to the organization but were then ignored.
• 01:14 This wasn't a methodology.
• 01:16 Another key attribute of the organizational methodology is that it
• 01:19 includes management involvement.
• 01:21 We don't have the project teams doing one thing and management doing something else.
• 01:26 Management does have oversight in the process.
• 01:30 And finally, I often see it now being implemented through an internal website or
• 01:34 some type of software that allows collaboration.
• 01:37 Remember that a key part of the methodology is communication.
• 01:41 Tools are used to improve and clarify communication.
• 01:45 Let's look at one of the very common types of methodologies,
• 01:49 known as the sequential or waterfall approach.
• 01:52 And for illustration, I will use a generic software development project.
• 01:56 As you can see,
• 01:57 someone from marketing or product management first gathers the requirements.
• 02:02 Then a product architect comes up with the concept.
• 02:06 When that concept is deemed acceptable, the project officially kicks off.
• 02:11 This concept is handed to the software engineers who create a product design.
• 02:15 There's a design review and design freeze.
• 02:18 And at that point, the coders start to write the code.
• 02:21 Eventually, all the code is written and
• 02:23 then there's a code review with a code freeze.
• 02:25 Now it's time for the testers to take over, testing and verification starts.
• 02:30 The critical bugs get fixed and the product gets launched.
• 02:33 Then the product moves to a sustaining support, and a whole different set of
• 02:38 people are involved responsible for keeping it working.
• 02:41 As you can see, each discipline does their work and passes the project along.
• 02:46 Each function focuses on technical excellence for their work.
• 02:49 Keep in mind that the goal is to reduce and eliminate risk.
• 02:53 And each function owns the problems in its area.
• 02:56 Issues have to be fully resolved before the project is passed to someone else.
• 03:00 Notice the project only flows one way.
• 03:03 So the functions must get everything done and do it right.
• 03:06 They will not have a second chance.
• 03:08 Again, this sequential or waterfall approach has been the traditional approach
• 03:13 used in many organizations.
• 03:15 Let's look at that same software development project that we used with
• 03:19 the sequential or traditional project, but
• 03:21 now we use it with a concurrent methodology.
• 03:24 As you can see, there is overlap between the activities of the different functions.
• 03:28 That is the reason for the name concurrent.
• 03:31 Requirements are gathered, but even before that activity is done,
• 03:34 concepts are being generated, which may lead to more detailed or
• 03:38 a deeper look at some of the customer requirements.
• 03:41 Once the concept is well underway, design starts.
• 03:44 This allows the designers to test some of the concept ideas and
• 03:48 feed those back to the product architect.
• 03:51 As a portion of the design comes into focus, the coding starts.
• 03:55 And as some of the software is developed, testing and integration is performed.
• 03:59 While there are still technical milestones like design freeze and code freeze,
• 04:04 they are softer milestones,
• 04:05 with open items that are not finalized until well after the milestone event.
• 04:10 This project is planned and managed by a multifunctional core team.
• 04:13 Each individual is a technical expert from their function and is responsible for
• 04:17 the overall success of the project, not just their functional success.
• 04:21 It's not a case of the project manager being king or queen,
• 04:25 rather they're a facilitator of the process.
• 04:28 This multifunctional team strives to meet all customer needs, both internal and
• 04:32 external.
• 04:33 Each core team member has a voice and a vote in the core team.
• 04:37 Issues are resolved by the team.
• 04:39 A problem in one function may be more easily accommodated in the work by another
• 04:44 function.
• 04:45 The team then constantly works to seek an optimal solution for the business.
• 04:50 So let's take this one step further and consider the adaptive methodology.
• 04:55 This methodology is most commonly used with agile projects.
• 04:59 One thing that you immediately see is that it is done in an iterative process or
• 05:03 with waves.
• 05:04 Instead of the fully integrated sequential or concurrent approach,
• 05:08 this approach takes a piece of the project work, completes that,
• 05:12 then goes and gets another piece and adds that into the original part.
• 05:15 In this example, I'm showing four iterations.
• 05:18 I've seen projects with as few as two and as many as 12.
• 05:22 During each of these iterations, multiple activities are done,
• 05:25 such as concept, design, coding, and testing.
• 05:28 This approach has grown out of the experience developed over years
• 05:32 by high tech startups.
• 05:33 A few people work to get a basic product ready to go, and
• 05:36 then they start adding features and functions in successive releases.
• 05:41 The approach relies upon a small interdisciplinary team
• 05:44 doing the work at each iteration.
• 05:46 By interdisciplinary I mean that each individual's able to do multiple tasks or
• 05:51 activities, they are not narrow specialists.
• 05:54 The approach is focused on performance, get this iteration to work,
• 05:58 and problems that are identified will be fixed on the next iteration.
• 06:03 And any issue can be resolved by anyone.
• 06:05 In fact, it's usually a case of you found it, you fix it.
• 06:09 If you have the knowledge and the capacity to work on a problem, work on it.
• 06:13 There is no such thing as that's not my job, that's his or her job.
• 06:18 So we've looked at several different methodologies.
• 06:20 Now in the next lesson, we'll compare them.

Lesson notes are only available for subscribers.