5 General Styles of Project Management

There are a number of well-defined project management styles, only some of which we will cover here. We could write an entire textbook on those styles, so don’t take the fact that a style name is missing here as meaningful. Only a few styles are being pointed out to show, later, how requirements gathering and requirements specifications vary from one project management style to another. We’ll only go into enough detail to make that comparison meaningful.

Note that like everything else in the world, each style of management has a reason behind it, and each methodology has its own advantages and disadvantages.

5.1. Waterfall

The Waterfall model assumes that requirements will be stable, and that the work will flow from stage to stage, never to return to its starting point, much like a waterfall. Within a Waterfall project, the Requirements team first gathers the requirements and writes the requirements documentation. Often, this (or these) specify what hardware and/or software is to be built, to a great degree of detail. This is often called “the A-Spec”. Following this phase, most or all of the Requirements team will leave the project, and only then will the Design team join the project. The Design team will do the system’s design work, laying out how the components will work internally, and how they’ll fit together. Any hardware will be designed, and hardware/software interfaces will be designed, and interfaces to or from the outside world will be specified, and often the internal API, class structures (if any), messaging (if any), and database structure (if any) will be designed. The result of this stage is a design specification, or “B-Spec”, which allows the programmers to pretty-much work on their own, because there should be no negotiation on how anything should work or interface left to do. At this point, all or most of the Design team will leave the project, and the Engineering and/or Programming team(s) will join. The programming teams will write the code, the unit test plans, and test their code. If there are any additional facts to add, which there certainly are when hardware is built or manuals are to be written, that documentation is added, called the “As Built Spec” or “the C-Spec”. At this point, much of this or these team(s) leave, and the Integration-and-QA team comes onto the job. It’s their job to get the system integrated and delivered.

In the real world, these phases don’t end or start all at once. Some teams will finish ahead of other teams, and some people will finish ahead of other team-mates. It seldom happens that the project manager will have enough people to have all the tasks in a phase done all at once, and so the teams and their members chew through the tasks, which means that some tasks will be pushed to the next phase before others are even started. Thus, even on a Waterfall project, deliveries will often be in phases.

There are some money and time advantages to the Waterfall model: Since the teams are only on the project while they’re needed on the project, there is a cost advantage there. There is also an overall speed advantage to the company if they can keep the teams busy, in that with several different teams, each of those teams can be working on a project at the same time.

And, there are some well-known disadvantages to Waterfall, too: Waterfall relies heavily on everything, especially the requirements, remaining completely stable. If the project moves from one phase to the next, and something in an earlier phase needs to be reworked, there can be a problem, because the team(s) that handle the previous phase(s) are gone, and either need to be recalled, or someone else has to pick up work they’re not familiar with.

Appropriate pricing models when Waterfall is being used for outside projects (also known as bespoke projects): If the customer presents a set of needs up front, and that set of needs leads directly to a set of requirements, then the project can be done at a fixed price. If things are not nailed down until the requirements are fleshed out, then the requirements can be done using a time-and-expenses contract, and the rest done as fixed price. Of course, all contracts can always be done as time-and-expenses. In the split version, some companies may choose to do the requirements gathering on speculation (which is like free, except that the price is figured into the fixed price portion), hoping to get the big sale. Typically, fixed price contracts will involve some money up front, then payments as deliverables are delivered, and then some final amount on final acceptance.

Sheldon’s advice (not widely accepted): When the requirements are extremely stable and well-known, go with Waterfall.

5.2. Rational Unified Process

RUP® or Rational Unified Process® is a tweak on the Unified Process by Rational Software, which is now part of IBM. In many ways, it’s part-way between Waterfall and Agile, in that it’s really more Waterfall-like, with some hints of Scrum.

RUP sees the work to be done in a project as (a) business modeling, in which the existing business rules and processes are flushed out, (b) requirements, in which the requirements for the system to be built are discovered, categorized, and documented, (c) analysis and design, in which the requirements are analyzed for patterns, and a design for a system that will satisfy the requirements is designed, (d) implementation, in which the system is built and/or coded, (e) test, and (f) deployment.

Despite having this six task areas, RUP divides the project into four phases, which are (1) inception, which is the ideas phase, (2) elaboration, which is the research phase, (3) construction, in which things get built, and (4) transition, in which we move from building to installing and running. RUP sees testing as happening all along the process. Within each of these four phases, there are “iterations”, which seem inaptly named, because they’re more like Scrum’s “sprints”.

In Waterfall, there is often a hard boundary. We design, then we stop designing. We build, then we stop building. We test, then we stop testing. But, in RUP, this is seen more like a collection of relatively flat and wide bell curves. We have our business modeling, which peaks and then starts to fall off. While business modeling is at its peak, requirements engineering is in its ascendancy. While requirements engineering is at its peak, analysis and design is at its ascendency, and so on. But, during all of this, testing has flurries of activity in each “iteration”, as various “artifacts” (documents, code, or anything else) are delivered to the QA people.

5.3. Agile

Agile is a big category. It involves any methodology where the requirements are expected to shift (or are allowed to shift), and describes the fact that the organization will have to remain agile in its approach, so that it can keep up with those changes. In just about all Agile variants, there is a queue of things to be done, called the “backlog”. As the project progresses, the requirements gatherers continue to gather requirements and update the requirements documents. The programmers start very shortly after the requirements gatherers do, and the QA people start the same time as the programmers, so that they can plan their tests while the programmers are producing what needs to be tested. The requirements presented to the programmers are not the whole set of requirements, but the requirements for what has to be done now.

Advantages: Very little should throw an Agile project for a loop. The whole team is there the whole time, and should be able to handle anything.

Disadvantages: The whole team is there for the whole project, and as things change, tests must be rerun often. Thus, virtually all tests need to be automated. This can have a higher cost for the production of the tests, and of course, there can be a higher cost due to the entire set of teams remaining on the project.

Appropriate pricing models: If development starts before the last requirement is known (which is the whole basis behind Agile), then it’s almost impossible to know the extent of the costs. Thus, time-and-expense estimates and time-and-expenses contracts are how these sorts of projects are normally billed out.

Sheldon’s recommendation: Except in the Waterfall case explained above, and periodic releases of packaged software, go with Agile.

Below are described several “flavors” of Agile. Note that the flavors described below can very easily be mixed within a project, on a team-by-team basis.

In all forms of Agile, the priority of each task is important, as well as whether one task needs to be completed before another task’s implementation can start. It is often fully or partially on the business analyst/requirements documentor to make this determination.

5.3.1. Scrum

In the Scrum version of Agile, there are fixed periods of 1-6 weeks, called “sprints”. At the start of each sprint there is a meeting run by the “scrum master”, in which assignments are handed out to developers from the backlog, or developers are allowed to choose assignments from the backlog. Generally, assignments are graded as to the expected amount of effort to complete. Sometimes these are estimated in hours or days, sometimes in “points”, which are just a relative order of difficulty (because some people work faster than others, “hours” for one person might not match hours for someone else), or just “small”, “medium”, and “large”. A developer may be assigned multiple tasks for the sprint, just one, or one task that may span multiple sprints. One or more business analysts are usually present at the sprints’ “kickoff meetings”. Each day, there will be a “daily standup meeting” in which the accomplishments and problems of the previous day will be discussed, as well as the plans for the current day. At the end of the sprint, there will be a “retrospective” meeting.

Sprints are usually numbered, and which sprint you’re on would usually have to do with which team you’re on. For instance, the Requirements team might be on their Sprint 10, while the Development team is on their Sprint 9, and the QA team is on their Sprint 8.

Advantages: Even the least self-directed people will have clear direction in this scheme. The daily standup keeps everyone producing and appraised of the situation.

Disadvantages: (a) There is a lot of meeting time involved. (b) Let’s say that there are a number of tasks that are slated to take 4, 5, and 6 days. If the sprint duration is 5 business days, then 4-day assignments are a bit too short to be convenient, and 6-day assignments are a bit too long to be convenient. These can lead to rushed and idle time. (c) The daily standup can be misused to keep everyone pushed to their limits, which can lead to burn-out. This can also lead to the “boy who called ‘wolf'” problem, in which something comes up that really does have to be accomplished quickly, and everyone treats it as if it were the standard priority.

5.3.2. Kanban

The name “Kanban” comes from the Japanese word “看板”, meaning sign-board. The idea here is that the backlog was posted in the form of index cards on a pin-board, and a developer ready for the next assignment would take one of those cards, evaluating priority, estimated time to complete the task, and personal affinity for the type of work on that assignment. Few if any companies still use cards and a pin-board, but the concept is certainly in use, in a more automated fashion. In this model, either the project manager (PM) or the business analyst will be in charge of the (typically virtual) “cards”.

Advantages: There is little meeting time involved. Tasks are not forced into an artificial time-box.

Disadvantages: Anyone in this system who is not self-directed is likely to be less productive.

Sheldon’s recommendation: Categorize your workers into the self-directed camp and the “needs direction” camp. Run one camp using Scrum, and the other using Kanban. Just before a Scrum kickoff meeting, the Scrum master will have to assign a number of “cards” to the Scrum team, and during the meeting, assign those tasks to individuals.

5.3.3. Extreme

Extreme Programming is a lot like Agile, except that we concern ourselves only with one function or functionality or feature at a time. In each sprint or cycle, we pick the single most important item, or the single most foundational item, or the single easiest item, and we implement that. But, we don’t just implement it. Let’s say that a feature will involve four functions. First, we write the test driver for the first of those functions we feel like writing, and add the test driver to the master test program. Then, we write the function that we just wrote the test driver for. Then, we run the master test program, and it tests our first function, and reports success and failure. After we’re at “success”, we can write the second test driver and the second function. After a few days, weeks, or months of this, we have hundreds or even thousands of automatically running tests, and if we ever break something along the way, we should know about it pretty quickly.

Another main tenant of Extreme Programming or XP is that we just do the minimum to clear a single requirement, knowing full well that a lot is going to change in the next few hours or days or weeks. This affects the requirements writing process, in that your software requirements specification will not be some tome delivered from on high as in Waterfall, nor the weekly news magazine of Agile, but more like the daily newspaper or hourly radio news update. In XP requirements engineering, it’s more like a constant stream of individual requirements to the programming team. And forget prioritization. The programmers will pick up individual requirements one at a time, in whatever order they see fit. Now, if the customer really wants one item before another, you can let the programmers know, and hopefully that will have some effect.

Although you’ll be delivering your requirements to the programmers in groups or one at a time, they’ll typically be reporting back “done” one at a time, or in groups. When I worked an XP-style project, we typically had releases during lunch and at end of day. We’d install before reporting “done”. So, you’ll need to keep a list of requirements, and whether they’re done or not. You won’t know what’s being worked on, only what’s done.

One more aspect of XP that doesn’t make much difference to the requirements engineers: In XP, programmers work in pairs. That allows one to do the work while the other is reviewing and checking the work. So QA and programming happen in very small teams. Each QAs the other’s work.

5.4. Hybrids

For the most part, anything that’s not in or very close to one of the categories above is considered a hybrid model.

5.4.1. In General

Like most things, hybrid models happen for “good” reasons and “bad” reasons. Whenever someone suggests any model, including a hybrid model, the project manager needs to assess whether the model is a good fit or not.

5.4.2. Wagile

“Wagile”, or “WAgile”, is claimed to be a hybrid between the Waterfall model and the Agile model. We use “claimed”, because Wagile models are not usually things that have been well thought out, but rather things that have just happened. Waterfall and Agile are so different in their goals and assumptions that Wagile is a lot like trying to go north and south at the same time. You may get somewhere, and you may not.

Meeting styles and task assignment styles alone are not enough to consider something a hybrid. For instance, in assigning tasks in a Waterfall project, the project manager may simply assign tasks to people or may let them pick from available tasks. Neither of those makes the project a hybrid. There may be weekly one-on-one or group status and progress meetings or a daily group meeting. Neither of those choices creates a hybrid either.

5.4.3. Spiral

Spiral truly is hybrid to some, and a distinct methodology to others. In the Spiral methodology, there are months-long Waterfall-like development efforts, each leading to a released version of the software. That’s followed by an overall retrospective and planning for the next session. So in a way, it’s like Agile with 6-12 month sprints.

Sheldon’s recommendation: This sort of methodology is optimal for the production of packaged software products. You can use a Waterfall methodology for version 1.0, and then when you go to trade shows, embed the requirements people with the Sales team, to get feedback from customers and potential customers on what should be released in the following versions.

5.5. Command & Control and Negotiation

In some projects, there’s a clear top-down control system, and there are orders, rather than negotiation. Those tend to be the easiest jobs to deal with. You won’t get into an argument if you can’t argue.

But, when that control structure doesn’t exist, or you’re dealing with outside customers, there will often be negotiation. That can be your department negotiating with another department about what can be done when and for how much. It can also be your company negotiating with a current or potential customer. In the interdepartmental negotiations, you’re all on the same team, and generally only really trying to decide what’s reasonable, who gets to have the easier time, and possibly even budget share. When you’re negotiating with an outside customer, you’re on opposite teams. You want to make a profit on the deal (usually money, but occasionally something else, possibly even an intangible), and so does the customer. A deal should only take place if it’s going to be a win-win situation — that is, both sides will be happy with the outcome.

That brings us to some key points of negotiation, some of which always apply, and some of which only apply to some situations:

• In an outside negotiation, be prepared to walk away. Remember that the negotiator for the other side is also prepared to walk away. That’s because neither of you wants to get stuck in a bad deal.
• Know your facts coming in, but also be prepared to say that there’s something you don’t know and will have to find out and get back.
• Keep it cordial. (Sheldon negotiated with Stan Lee once. Stan was the hardest bad*** ever, while at the same time, being the nicest guy in the world.) Even if you lose the job, you want the opportunity to bid next time.
• Know what you’re trying to get. To the extent possible, try to know what the other side is trying to get too.
• Don’t lie, but at the same time, if you’re dealing with an outside company, you don’t have to tell the whole truth either. For instance, if your estimate is $50,000 to do a job, and someone from another department tells you that there is $100,000 budget for the job, let them know it’s a $50,000 job. But, if you’re dealing with an outside customer, and you know it’s a $50,000 job, and they offer $100,000, the correct response is something on the order of “Can you do $125,000?”.
• Have a presentation ready to go, but remember that you may have to throw that presentation away and head off in a different direction at a moment’s notice.
• Of course, try to end with a sale or agreement or whatever is appropriate
• Don’t get emotionally involved.
• Don’t get worried.
• As with all engineering matters, have the ego of a Zen master — present only when needed.
• Be realistic

5.6.  Others

Of course, there are other styles of project management possible. People come up with completely new ones, people make hybrids (intentionally and often unintentionally), and some have no clear methodology at all.

5.7. How Things Can Go Wrong

Picking the wrong project methodology, or at least the wrong major category of project methodology, can be a major financial issue, even if everything technical goes just right. Fixed price projects can be a disaster using Agile. Projects with the likelihood of change can be a disaster with Waterfall. Don’t just pick a method and do everything that way without first considering other options.

5.8. Discussion Questions

1. Do you think there is one best style of project management? If so, why?
2. Do you think that each style of management has an affinity for a certain set of circumstances? If so, what are some of those affinities?
3. Do you think that some style of management is never the best option? If so, what and why?