Enhance Your Effectiveness in Managing Projects with These Top Approaches

If I tell you, “Measure twice, cut once”, what will you understand?

You will most likely note the implication behind the statement, that once you cut (referring to any decision taken), that’s it, there is no undoing it. Similarly, once you understand the project requirements, design the system, and then start implementation, if you discover that the methodology is wrong, stepping back and redoing it will cost a whole lot, and also may be impossible.

In other words, the Waterfall approach to project management is a sequential development process. It was first proposed by Winston W. Royce, way back in 1970. The flow made logical sense, and there were no alternatives available, so it quickly found favors from managers.

It refers to a flow through different stages without an easy way to go back to earlier stages and redo things gone wrong. Different phases of a project can typically be requirements analysis, design, implementation, testing, deployment, and maintenance. The work at a particular phase is completed before moving on to the next phase.

Here’s an overview of the different phases of a project:

Requirements Phase

In this phase, you talk to the business users and end users to understand all of the system requirements, then document and analyze them. The team also understands all the system requirements such as scalability, reliability etc. The outcome of this phase is Requirements Understanding Document (RUD).

Design Phase

Remember that once you are out of a phase, the output is pretty much unchangeable. You don’t keep going back and forth, in this approach. The team takes all the requirements and creates system design. They define the components, interfaces, data layers, networking infrastructure, user interface etc.

The design phase is typically divided into: 

• High Level Design (HLD) phase which deals with the overall system design and architecture.
• Low Level Design (LLD) phase which deals with the module-level details, sometimes including the pseudocode (for software projects).

The outcome of this phase includes HLD and LLD artifacts.

Implementation Phase

Using the HLD and LLD, the implementation team can now jump into the actual work of building the product. The design specifications are turned into working code. The modules are integrated as per the interface design contracts, and unit testing is completed by the development team itself.

Verification Phase

Also known as the Testing phase, in this phase the Quality Assurance team takes the code from the development team and tests the functionality as per the requirements gathered. The integration testing may bring out bugs, faults, and errors to be fixed by the development team. The lesser the defects, quicker will be the delivery timeline and lesser will be the cost.

Deployment Phase

In this phase, the developed code is deployed into a live environment and tested for performance (non-functional requirements). At times a small subset of the end users is given access to the system to gauge its performance. Finally, the tested product is released in the market.

Maintenance Phase

In this phase, the team provides support to the product. Any issues, defects, and even feature enhancements are undertaken. This is either done by the original development team, a new support team, or a mix of these members. In some cases, the support or maintenance duration is much longer than the overall development time. In other cases, the customer’s team is trained to maintain the product by themselves.

• The requirements are expected to not change till the product is available
• Work is 100% completed and signed off at each phase, and only then moves to the next stage
• It may take several years before the stakeholders ever get to see the completed outcome of the project

If you try to apply this to, say, developing a software product, then you are almost guaranteed to have additional cost and time up to when the outcome is produced. Then you face pretty much like a ‘round hole—square peg’ problem; where the solution mismatches the problem.

Consider these important points:

• Clients hardly know upfront exactly what they want in their product
• End-users can only tell whether they like a feature only after seeing it in action
• By the time a product is developed, the market dynamics might have changed, requiring changes to behavior and features

So, you can see why the Waterfall approach is not a great fit for software development. But for quite a few projects, especially in Construction, Manufacturing, and even Pharma domains, Waterfall is a great model.

If you want to learn more about this, check out this course from Projectmanagement.org. Alternatively, check out this course, which is quite comprehensive.

If you are a Rugby fan, then the word Scrum could ring with you because the terminology is borrowed from the game itself. It is a short word for ‘Scrummaging’, which is a way of restarting a game after a penalty or after the ball has left play.

How is this relevant?

Because in a Scrum approach, the work stops and starts in short phases. And in each of these short phases (called as Sprint or Iteration), work is planned, and the outcome is reviewed. This is done using an approach called ‘Inspect and Adapt’. As you can see, this helps to incorporate changing requirements into the development process.

Scrum breaks down major features of the product requirements into a series of small, and manageable tasks. The team delivers each of these tasks at the end of the sprint. Generally, each sprint can be of 2-4 weeks duration. Scrum recommends a daily meeting called “daily stand up” or “daily scrum” where each member of the team takes a minute to answer 3 questions:

• What did I work on yesterday?
• What am I working on today?
• What are my challenges?

There are actually 3 roles inherent in Scrum that makes success of the team possible:

• Scrum Master: The person who is responsible to ensure the team and management develops an Agile mindset and helps the team deliver as per the agreed upon agile processes and practices
• Product Owner: Who is the bridge between customer and team by delivering requirements and clearing doubts and questions on a daily basis
• Development Team: Which does the actual work by collaboratively designing, developing, testing, and improving the process that produces the outcome

All the requirements are maintained in Product Backlog, prioritized based on business needs by the Product Owner. These items are then scoped into a specific Sprint by the team, in discussion with the Product Owner. The team holds the planning meeting at the beginning of each Sprint. At the end of the Sprint, the team conducts 2 ceremonies:

• Product Review to showcase the output of the sprint to all the interested stakeholders.
• Retrospective Review where the team discusses the process to identify improvement points

Scrum, by far, is the most used Agile framework. And there are good reasons for this.

• Scrum allows flexibility: You can add, remove, or change any requirements until the time a sprint begins.
• Scrum facilitates good quality work: As the team is given full authority to work as they deem fit, the onus of the project is borne by them, giving them additional incentive to perform well. This produces good quality work because there is no external pressure or external force dictating work. Also, the quality is measured right at the end of the sprint by the stakeholders during product review.
• Scrum makes customer satisfaction easy to achieve: Customers can change requirements until the team takes up a feature for an implementation. Customers see the outcome of a sprint at the end of it. They can provide feedback anytime during or after a sprint.

Now, the Scrum approach to project management is a skill that every project manager must have. I would recommend this course, or this 2-day virtual classroom course for you to get started with.

Imagine that you are the project manager of a colossal project to fix defects in a complex, legacy, enterprise software product. You would need a way to take high-priority defects with a quick turnaround. But you cannot fix the scope of a sprint because a high-priority or critical defect may be discovered any time. Then, it is a natural choice to club Scrum and Kanban; use Scrumban, a pull-based system (a system that works on the basis of project requirements).

Scrumban gives you the structure of the Scrum approach, plus the flexibility and visualization of Kanban (recall the Kanban board). This makes it a useful approach to manage complex workflows.

• Work iterations are kept short, to provide the necessary flexibility to the pull-based system
• Planning is on demand, and happens when the planning trigger goes off. You define the planning trigger yourself, like a certain number of to-do items left on the board
• The top-down approach is based on the Bucket size. The 3 buckets refer to different stages of planning, and typically of 1 year, 6 months, and 3 months duration
• The visual representation is the same as in Kanban, with the board sporting 3 or more columns (such as To-do, Doing, and Done)
• The in-process items are limited, to avoid bottlenecks while working on too many items at the same time

Apart from the legacy system example we saw earlier, there is another situation where you’ll find this useful:

Use it when you have to transition from Predictive to Agile environments.

How?

Kanban is known as the ‘start where you are’ approach. This means, you can plug in this approach in any system. Simply identify the components that can be done in a pull-based manner and implement Kanban there. With that in place, the next logical step is Scrumban. This is where you do the Kanban work with a Scrum approach. From there, you can move the entire work into Scrum methodology, eventually.

As you can see, Scrumban is a powerful project management approach and will do you a world of good to learn. I would recommend the Scrumban course from developintelligence.com.

James Martin proposed Rapid Application Development (RAD) for quick development of software projects. This approach has less focus on planning and more on development using an adaptive process. This is usually done with the Prototype approach.

One of the prominent uses of RAD is for developing software that is driven by User Interface (UI) needs. The UI developers use tools and quickly build the required user interfaces. And then the developers develop functionality to suit these UI needs. This approach accelerates the overall development effort.

James Martin defines RAD approach in 4 phases:

• Requirements Planning Phase: In this phase, the team discusses the business requirements, product and project scope, and system requirements. Then they refine it and finalize it before moving to the next phase.
• User Design Phase: In this phase, the system analysts work with the end users. They understand end users' usage patterns and interaction with the system and develop models and prototypes. These models and prototypes have to represent the system behavior as accurately as possible. The teams use various tools and techniques (such as CASE tool, and Joint Application Design) to create these models from user needs.
• Construction Phase: In this phase, the team implements backend development as per the user interface contract. The end-user participation continues in this phase as well. This involvement ensures that any changes are implemented quickly to avoid surprises at a later stage. The complete cycle of coding, unit testing, integration testing, and system testing are done in this phase.
• Cut-over Phase: This phase typically consists of system integration, final documentation, and user training.

Since this approach compresses the entire development cycle, users get to see what they have in mind at least some version of it-pretty quickly. Thus, many IT systems are built using a certain level of RAD.

Some of the advantages of this system are:

• Reduced Risks: Since users get to see the system much faster and users are involved throughout, the risks are greatly reduced. More risks are identified early into the life cycle, making their mitigation possible. The prototype approach itself helps unearth risks due to the inherent complexity of the system under construction.
• Control Over Quality: Since user involvement is expected right from the planning stage, the requirements are understood better. And with quick feedback, the level of quality is also maintained. This approach allows for quicker turnaround—both from the users on requirements and from the team on the completion of prototypes and models. Compared to other approaches, RAD has this benefit.
• Better Control Over Schedule and Budget: RAD takes an adaptive approach, where the output is built iteratively or even incrementally. The requirements are given by the end users, and feedback is taken by the team by working closely with each other. This aspect gives the team better control over the schedule and budget.

Want to learn the RAD approach for your projects? Check out this course from Skillsoft.