Project Management Framework vs Common Sense

Recent Agile Network India event in #AhmedabadChapter, following two insightful sessions, we engaged in a panel discussion. I was a part of panelist and in Q&A session, Kartik Dhokaai posed the thought-provoking question: “Project Management Framework or Common Sense?” I found this topic fascinating and am excited to share my perspective.

Definition

Let's begin with a layman's language terms, project management framework is undertaking a group of activities/processes to accomplish specific goals.

There are three pillars of fundamentals for each project management framework.

• Scope - List of activities or Tasks to perform

• Time - Task needs to complete in provided Timeline

• Cost - Project budget decided based on financial constraint

Here, I like to share about popular project management methodology like Waterfall, Scrum, Kanban, Prince 2, XP, Lean etc.. These are structured methodologies or guidelines that provide a systematic approach to managing projects. While I won’t delve into the specifics of each individual framework, you can easily find a wealth of information and resources on Google.com

I'd like to go through real-time scenarios we faced while executing the project.

Situation 1: In project execution process, client requested for the changes which was not addressed in scope. As a framework policy, we should ask client approval before proceed for the changes, Team cannot integrate the CR (Change Request) without PM(Project Manager) confirmation. Here, as a PM, he should apply common sense to identify the CR values. If Project cost was $4000 and CR amount $400 to $600 then we should wait for client approval but if the project cost is $10000 and CR amount is $100 then apply the common sense, PM give an approval to team to start changes. Here, PM has 1% risk only but in $400 CR amount, risk is 10%.

PM should understand the overall Project cost and compare with CR value. Do not follow the framework which said Client approval is must before start working on CR.

Situation 2: In the project execution cycle, smaller-sized projects are typically divided into milestones, while large-scale projects are divided into phases. Within each phase or milestone cycle, there are key activities such as Design, Development, Testing, Demo, Deployment, and Feedback. As a project manager, it is crucial not to deliver milestones to clients with known bugs. Instead, PMs should adopt a pragmatic approach, analyze the project’s current status, identify the reviewers/stakeholders, and assess the criticality of the delivery.

While some rigid bookish PMs adhere strictly to decisions, in my opinion, PMs should be adaptable and consider the context. For instance, if a project has five milestones and we are delivering the first or second milestone, it may be acceptable to provide the client with deliverables containing some bugs, along with an assessment of their criticality. If certain bugs impact project functionality, we can communicate with the client to avoid reviewing those specific areas, especially if the team is actively working on resolving them.

However, it’s essential not to extend milestone delivery dates solely due to bugs. Clients can become frustrated if they encounter bugs after a delay caused by bug fixing. Ultimately, as we approach the final milestone (the fifth) and prepare for end-user delivery, all remaining bugs should be addressed to ensure a successful project completion.

Conclusion

Regardless of whether the project is large-scale or small, the team size is small or big, the project management methodology is agile or waterfall, the project is dedicated or on a fixed budget, or whether it is in the initiation phase or nearing completion, it is essential to apply common sense rather than rigidly adhering to a specific framework rules.

In summary, while frameworks provide structure, common sense injects practicality. The best approach lies in blending the two, leveraging the strengths of each to achieve project success.

#ProjectManagement #ProjectManagementMethodology #Agile