Project Life cycle management Architecture

Project management and business analysis often undergo similar challenges to adopt the right approach. Earlier it was easy with limited options. When we have more available options, the demand for better efficiency, and better outcome, the industry demands better planning approach. The responsibility of the Leader to select the appropriate methodology becomes critical.

To be precise, any approach that can give the desired outcome is the best. But how to decide on the best. The popular methodologies are Waterfall, V-model, Agile, Kanban, and Scrum. However, based on different situations and demands, other approaches are also being adopted. While these methodologies have significant differences, it’s necessary to acknowledge that each project management methodology ultimately has the same goal. The aim is to facilitate the completion of projects and achieve the desired outcome.

Earlier in software programming, the researchers and developers used to be the same person. They were solely responsible and get mingled in the business analysis, design, and monitoring activities. However, there was a downfall as and when the project requirements become complex, and it involves more engagements like meetings, discussions, and getting subsumed into the business functionalities and less time in builds — impacting the delivery.

These days, every project comes with a tight deadline, and spending more time in the non-delivery activities and impacts the project timeline and delivery milestones. Moreover, technical experts always want to focus on how — how to design and develop the solution. Hence the concept emerges to stop bothering the developers as they have to build critical logic, and too many inputs might have an adverse impact.

To support the developers, the framework was introduced to keep an overarching layer of experts. The information passes through multiple hops, and the aim of the requirement is almost lost before it reaches the developer. However, some consider these additional steps as the opportunity to refine the real implementation as a part of solution designing before actual implementation.

That has gradually become a cumbersome process to get the requirement agreement as it started enforces to follow a series of changes in terms of procedural requirements, artifacts required for different project management. It might not be directly because of practice followed but as a need from creating more values for the organization to produce more quality products. The process starts with waterfall modelling or following the V-model and iterative way of project management. Nothing is good or bad and is perspective in nature. Someone might be good in understanding, forecasting, and estimating the requirements — let’s say hypothetically near about 90 percent based on his/her experience, and jumping into the problem solving with the big bang delivery approach might be ok. However, that might not be the case with others.

Several CIO reports indicate that many of the projects with a lack of proper Business Analysis ends-up with 40–45% additional efforts in defect fix or re-work. Thus, emerges the need of understanding the Business Analysis Knowledge Areas — understanding Business case/proposals and business outcomes. Design the solution for the business outcomes, different guidelines to ensure the impact of getting business efficiency and financial benefits has no adverse effect on scalability, agility, and maintainability of the products. There is always a debate if designing, following guidelines, or creating artifacts for management functions is needed. Some consider that as effort waste. The outcome is the end product or efficiency-oriented delivery but at the end of the project. Hence, many different thought processes emerged. Someone finds a phased approach as the best, and for others, scrum/Sprint-based delivery is the best. The phased approach promotes the execution of multiple independent project phases in parallel whereas, the sprint follows a pattern of sequence.

The standard way to decide the project management method to be adopted are based on basic 4 approaches:

· Process improvement approach

· Previous experience-based confidence driven approach

· Deadline / milestone driven approach

· Outcome driven approach

The hybrid approach emerged from all of them, taking the best feasible techniques from most methodologies and worked for many project deliveries:

All of them might not be feasible for less complex projects. However, in the long run, it is beneficial to build operational efficiency. If there is a compliance or audit requirement, then a formal document is required even in Scrum — especially in financial projects.

· Waterfall project management supports functional decomposition into linear and sequential stages, where every piece of the project relies on the completion of preceding deliverables.

· The adaptability of Agile is particularly well suited to projects where requirements or constraints are volatile and required to change. While projects should avoid such alterations when possible, Agile methodologies let teams adapt their process to accommodate such changes.

· Kanban board keeps transparency between team members, and it helps teams identify where processes need improvement. It makes problems like bottlenecks visible, allowing the team to make corrections as needed.

There are several other methodologies that are beneficial in process Improvement:

· Six Sigma: A data-driven approach to reduce defects to improve an organization’s performance.

· Lean manufacturing: A systematic process to minimize waste without sacrificing productivity.

· Total Quality Management (TQM): An organization-wide effort focused on continuous improvement to improve customer quality.

· Just-in-time: Methodology centred around reducing inventory costs, manufacturing products only as they’re needed.

· Theory of Constraints: A systematic process focused on finding and eliminating constraints.

In my view, the customized project execution architecture suited to the project environment will give a better outcome.

Below is one such high-level execution architecture:

- the execution process has been abstracted from what is required to implement

- the automation for the feedback loop — managing backlog, Change process, release process, monitoring, and defect management.

- more emphasis on the agile extreme programming and artifacts build is automated

- opportunity to build traceability and KPAs.

The continuous integration will be the enabler of all these and will be beneficial during execution and even post-project delivery in hyper care and operational support.

Note: The views expressed in this article presentation are mine and my organisation does not subscribe to the substance, veracity, or truthfulness of my views