Wednesday, September 16, 2015

PMBOK Framework vs Agile Methodology

PMBOK Framework vs Agile Methodology

PMBOK Framework
Agile Methods

XP eXtreme programming
SCRUM
FDD Feature Development
Project Integration Management
·         Develop Project Charter
·         Develop Preliminary Project Scope Statement
·         Develop Project Management Plan
·         Direct and Manage Project Execution
·         Monitor and Control Project Work
·         Integrated Change Control
·         Close Project

·         Integration of software as soon as possible and as often as possible (mostly related with software code)
·          Collective code ownership
·         Project velocity measurement
·         Verification of management approval and funding during planning phase
·         Validation of development tools and infrastructure during planning phase
·         Strong change management  procedure with product and sprint backlog
·         Refinement of system architecture to support changes
·         Postgame phase
·         Development of the overall system model
Project Scope Management
·         Scope Planning
·         Scope Definition
·         Create Work Breakdown Structure (WBS)
·         Scope Verification
·         Scope Control
·         User Stories
·         Release Planning, Small Releases 

·         Perform domain analysis for  building domain model
·         Development of a comprehensive product backlog list
·         Development of a comprehensive  product sprint backlog
·         Definition of the functionality that will be included in each release.
·         Selection of the release most appropriate for immediate development.
·         Review of progress for assigned  backlog items
·         Perform domain analysis for building domain model (step1).
·         Build Features List, subject areas  (step 2)

Project Time Management

·         Activity Definition
·         Activity Sequencing
·         Activity Resource Estimating
·         Activity Duration Estimating
·         Schedule Development, and
·         Schedule Control
·         Release Planning
·         Iterations planning
·         Definition of the delivery date and functionality for each release
·         Monthly iterations
·         Determine development sequence (step 3)
·         Assign Business Activities to Chief Programmers (step 3)
·         Assign Classes to Developers(step 3)
·         Chief programmer work package.

Project Cost Management
·         Cost Estimating
·         Cost Budgeting, and
·         Cost Control project
·         Not Available
·         Estimation of release cost, during planning phase
·         Not Available
Project Quality Management
·         Quality Planning,
·         Perform Quality Assurance, and
·         Perform Quality Control
·         Emphasize on testing(unit, acceptance)
·         Based on simplicity
·         Use of project standards

·         Distribution, review and adjustment of the standards with which the product will conform
·         Design review meeting
·         Sprint planning meeting
·         Sprint review meeting
·         Daily scrum

·         Review meetings (all steps)
·         Code inspection and unit test(step 5)

Project Human Resource Management
·         Human Resource Planning
·         Acquire Project Team
·         Develop Project Team, and
·         Manage Project Team
·         Personnel rotation to various positions
·         Pair programming
·         Good working conditions(no overtime)

·         Appointment of project team(s)  per release
·         Team participation in sprint meetings
·         Team participation in daily scrums
·         Appoint modeling team (step1)
·         Appoint feature list team(step 2)
·         Appoint Planning Team(step 3)
·         Appoint Feature Team (step3)
Project Communications Management
·         Communications Planning
·         Information Distribution
·         Performance Reporting, and
·         Manage Stakeholders
·         Use of system metaphor
·         Customer always available
·         Daily meetings
·         Use of project standards

·         Design review meeting
·         Scrum meeting
·         Sprint planning meeting
·         Sprint review meeting
·         Communication of standards to the project team

·         Review meetings (all steps)
Project Risk Management
·         Risk Management Planning
·         Risk Identification
·         Qualitative Risk Analysis
·         Qualitative Risk Analysis
·         Risk Response Planning, and
·         Risk Monitoring and Control
·         Create prototype to limit risk

·         Initial assessment of risk during pregame
·         Risk review during review meetings

·         Not available

Project Procurement Management
·         Plan Purchases and Acquisitions
·         Plan Contracting
·         Request Seller Responses
·         Select Sellers
·         Contract Administration
·         Contract Closure

·         Not available

·         Not available

·         Not available

Table above proves that agile methods do not define all facets needed in order to cover all aspects of project management, in the traditional sense. This was partially expected since traditional project management processes are fully defined compared with agile methods that are considered “practical”

Following Agile methods are giving emphasis in the following knowledge areas:
·         Scope Management, since emphasis is given in managing requirements
·         Human resource management, since emphasis is given in team work
·         Quality management, even though not formally defined, use of standards, testing and frequent reviews are promoted.
On the other hand, agile methods do not fully address the following knowledge areas:
·         Risk is not managed explicitly
·         Cost management is not part of the agile methodologies
·         Procurement management is not addressed at all
This implies that connecting agile methods with PMBOK will benefit the software project management community


Connecting The Dots Between Strategy and Execution

Connecting The Dots Between Strategy and Execution

“Strategic Execution” is one of those nebulous concepts that everyone claims to understand, but no one can really define.  It seems self-explanatory that effective strategic execution should start with a well-defined strategy, but this is unfortunately where many executives lose their way.  Rather than focus too much on strategy, everyone wants to jump directly into “execution,” because that is where leaders think they can have the most immediate and direct impact.  But executing anything without following the strategic reason for it is like putting the cart before the horse.
Strategy isn’t really all that difficult.  It is simply the purposeful decision to be something by a certain time in the future.  Seriously, its that simple.  If your organization decides it wants to be the recognized market leader in widget distribution by 2050, you’ve just established your strategy.  Good strategy is really about setting a goal, picking a niche, considering internal and external factors and establishing a deadline.  Strategies can take many forms across the spectrum of time.  Long-term strategy is usually a “softer goal” that defines the organization’s intended place in the market, while mid-range strategies are typically more focused and include specific areas of operational improvement or adjustment, milestones and more detailed plans or objectives.
By the time a strategy has been thought out, defined and planned, it begins to take on more of an implementation or execution-based look and feel.  Rather than statements of intention, execution plans define specific actions, approaches, timeboxes and resources being put to task in making the strategy real.  Sounds a lot like project management all of a sudden doesn’t it?  That’s not by accident.  In fact, that is why project management exists!  To bring order to a set of activities that are purposely designed and planned to bring about organizational strategy.

Projects, and project management approaches, are the ultimate mechanism through which organizational strategy is delivered.  For most, the execution of strategic direction requires that a number of projects be initiated, each with a unique and varied impact across the entire organization.  This requires a high degree of skill and knowledge in the areas of organization, prioritization, compromise and planning.  Many companies tackle this challenge through the use of project portfolios.
Portfolios serve as a great “middle man” between strategic intent and actual delivery.  They are commonly used to organize all of the project-based work needed to meet strategic plans and then seek to optimize available organizational resources by establishing a schedule or roadmap of project execution.  The goal of any portfolio-based approach is maximize the value of the overall portfolio investments and to balance the strategic fit, timing and sequencing, investment risk, operational capability and resource capacity.
Within a portfolio, the actual work is completed via individual projects and by following project management discipline.  The execution of any great organizational strategy happens at the project level.  Because of the delivery-based discipline, the control mechanisms used for potential changes, the measurement of performance metrics and the management of risks and issues, project management serves and a vital tool for strategic execution.
Strategic implementation, on the other hand, involves making decisions regarding how the organization’s resources (i.e. people, processes and systems) will be allocated, aligned, prioritized and mobilized towards achieving the identified strategic goals and objectives.  Successful project execution also results from activities that are well planned, communicated, aligned from top-to-bottom, monitored, controlled, managed and rewarded.
Strategic execution remains both a buzzword and a legitimate focus for executive management teams.  Strategic planning and road-mapping activities are often much easier than the bare-knuckle hard work that comes with executing those plans.  But smart executive teams, the one’s with an effective project portfolio system and highly-skilled Project Management Office, will be able to leverage those tools, resources and experts for successful competitive advantage!

Core of Project Management Artifacts

Core of Project Management Artifacts









The SDLC is *NOT* a Project Management Methodology

We need to institutionalize the SDLC as our organizational project management methodology” – The Ill-Informed, Buzzword-Loving Senior Executive
A common misperception amongst project stakeholders is the erroneous belief that the Software Development Life Cycle (SDLC) is a project management methodology.  There are even some who believe the inverse, that the SDLC is contained within traditional project management methodologies.  In truth, neither are quite correct, and it’s more than just semantics.  Here’s why…
The Software/Systems Development Life Cycle is a methodology that forms the framework for planning and controlling the creation, testing, and delivery of an information system.  More specifically, the SDLC process is composed of a number of clearly defined and distinct work phases which are used by information technology resources, such as systems engineers and systems developers to plan for, design, build, test, and deliver information systems.  The SDLC is about quality, consistency and product delivery in the realization of a product’s requirements.  In recent years, SDLC methodology has been modified to become more streamlined and less “waterfall” based, with the popular Agile approach being one example.  In most circumstances, the SDLC process is managed by a AppDev Manager, Business Analyst, Systems Analyst, SDLC Team or other systems development professionals.
Project Management Methodology on the other hand, is the application of knowledge, skills, tools and techniques to meet project requirements through planning, organizing, measuring, controlling and reporting upon resources (human, financial and time).  Best practices within traditional project management discipline list five main phases or “process groups” that include Initiating, Planning, Executing, Monitoring & Controlling, and Closing. The management of a project includes identification of requirements, balancing stakeholder needs/expectations/concerns and balancing competing constraints (scope, quality, schedule, budget, resources, and risk).  Within each phase, tasks are defined to move from one phase to another until the project is closed.  More recently, modifications to the traditional five-phase process have been developed to more appropriately address specific project management needs such as Prince2, Critical Chain, Lean and Benefit Realization.  Again, in most circumstances, the PM methodology is managed by a Project Manager or other project management professional.
In reading the last two paragraphs, you can immediately see the cause for stakeholder confusion can’t you?  Both methodologies use the same language:
  • Planning
  • Controlling
  • Phases of Work
  • Tasks
  • Requirements
Despite the similar language, care should always be taken to distinguish between the project life cycle and the product life cycle.  The important distinction being that the SDLC is completely focused on the phases, tasks, resources and plans needed to deliver information systems.  Project management methodology is more agnostic.  It’s process set and approach can be applied to any temporary endeavor with a defined beginning and end, whether it’s a construction project, a school research project, planning a move from one city to another or even an IT infrastructure upgrade project.
Now that the differences have been established, let’s spend some time on how and why the two can, and should, co-exist on any information system delivery project.


The project kicks off in the Project Management Initiation Phase.  The initiating processes determine the nature and scope of the project and produce the Project Charter, which serves as the project’s guidepost of what is expected to be delivered, in what timeframe, under what constraints (schedule, budget or quality) and leveraging which key resources. The Initiation Phase is also commonly where projects are reviewed and approved by a larger project portfolio or governance board.
With some kind of approval to proceed secured, the project enters the Planning Phase in the PM methodology.  Early in this phase, the project is planned to an appropriate level of detail, with the main purpose being the identification of project deliverables, establishment of key milestones and the assignment of resources to the effort.  Running in parallel on the SDLC process track, work activities focus on analyzing user needs and developing business and system requirements.
While the PM process progresses into breaking down the deliverables into tasks, sequencing those tasks and estimating resource effort vs. capacity, the SDLC track is busy with the System Design phase where the requirements that have been gathered are used to outline the desired features and system operations in detail, including screen layouts, business rules, process diagrams, code templates and other documentation.
Once the project plan is in place, the schedule set and the budget established, the project enters the Execution & Control Phase on the PM Life Cycle.  Here, actual coding and development tasks are started and test plans are documented.  Blocks of code are gradually completed and unit tested, leading to system functionality being delivered.  Issues are tracked and worked, while risk begins to decrease as more key milestones are met.
As the bulk of the coding and development tasks begin to wind down, testing activity starts in the SDLC Test Phase.  There is commonly an iterative relationship between Development and Testing as coding defects are discovered and sent back to development for fixes, which are then tested again until approved.  The project phases of Execution and Control also become iterative, continuously looping between tracking the execution plan and making adjustments based on the actual results via control mechanisms like earned value management, task completion, budget and schedule tracking and stakeholder management.  At the conclusion of these parallel tracks in both the SDLC and Project Management methodologies is the implementation/deployment of the final, tested solution.
Finally, the project management process wraps up the project by confirming that the delivered solution meets the scope parameters and requirements identified at the beginning of the effort.  Lessons learned are captured, documents are closed out and filed, resource recognition and celebrations are held, the system is handed off to the operations team and the project is officially closed.   But the SDLC process takes one more step (not shown above), starting with that hand-off to the operations team.  Known as the Maintenance Phase, the implemented solution is managed in a day-to-day operational state, where changes, enhancements, fixes and end-of-life planning considerations are made.
So remember, the SDLC is *NOT* a Project Management Methodology.  The two should never compete against each other during the life of a project initiative.  In fact, the two are completely complimentary to each other for information systems development projects.  In a perfect world, the PM processes should be led by a Project Manager and the SDLC processes should be overseen by a Systems Manager.  In an imperfect world, the Project Manager should at least solicit the help of a systems developer to ensure the SDLC best practices are defined and tracked on the systems development side of the effort.