This article represents high level view of project management and incorporates best practices of PMBOK 4 & XP and SCRUM agile methodologies. The basic objective of this article to enlighten process interactions in environment where phase to phase relationship is iterative and agile methodology is used. PMBOK 4 defines project management knowledge areas sequentially with well defined interfaces, here my focus is to define project management in high level as per process interactions.
Assumptions:
1. Phase to phase relationship is iterative; scope is managed by continuously delivered increments with a preference to the shorter timescale from a couple of weeks to a couple of months. Project team members are acquired for throughout the project, requirements are prioritize to maximize business value and minimize risk to the project.
2. Process of release planning is performed according to XP. Result of release planning is product backlog that is Key artifact of SCRUM. Here process is followed as per XP but also fulfils all the characteristics of product Backlog.
3. Refactoring concept is taken from XP.
4. Pair Programming and continuous integration is taken from XP.
5. Iterations are performed as per SCRUM.
6. PMI process concepts are incorporated for all the knowledge areas, where both XP and SCRUM do not say anything.
Project Initiation:
A project is started when Project Charter formally approved. Project Charter development is an integration process because it explore all other 8 aspects (scope, schedule, cost, quality, human resources, risk and procurement) of project in high level form.
High level project requirements are indentified and WBS is decomposed to milestone levels, in case of agile WBS creation is very much clear(Scope), summary milestone schedules are identified (Schedule), summary budget is established (Cost), success criteria are identified which forms basis of how identified high level features will be delivered (Quality), forecast of the resources is performed for the company investment analysis, some resources are pre assigned and acquired (Human Resources), High level risks are identified (Risk), and high level analysis is performed to analyze need of suppliers and purchase of good or equipments (Procurement).
When project initiation is completed we have two key outputs: Project Charter and stakeholder register. This project charter is progressively elaborated with the help of stakeholders identified in stakeholder register.
Stakeholder identification process included in communication knowledge area, as project communication is identified and implemented for the identified stakeholders. First time stakeholder register is developed in project initiation and during subsequent iteration of initiation process (i.e. during phase/iteration initiation) stakeholder’s objectives and influences are reviewed.
Stakeholder’s identification is continuous process, main focus is in initiation but it is also updated during planning processes (i.e. Define Scope, Plan Communication), during execution processes (i.e. Direct & Manage Project Execution) and during Monitoring & Control process (i.e. Monitor and Control Risks when SME are identified to initiate analysis of newly identified risks).
Project initiation is completed and now we are in planning processes. First step is to identify phase to phase relationship. Project phases are identified in project initiation. When we use agile methodology then phase to phase relationship is iterative, in evolving and largely undefined and rapidly changing environment.
Life cycle structure is refined where we identify processes for each phase of the project. Management plans for each knowledge area are tailored to the specific needs of the project; in addition change management and configuration management plan is tailored to the needs of the projects. It is project manager responsibility to gain buy-in for all of the management plans to establish common understanding of plans before actually doing it. Project stakeholders including customer should be educated about management plans to get necessary support for the planning.
Project Planning in detail: When phase to phase relationship is iterative then scope is delivered in small increments, project team members are involved throughout the project and requirements are prioritized to minimize project risks and maximize business value.
1. We have stakeholder register and stakeholder managements strategy already developed as part of project initiation so project communication planning is performed. Need and techniques of communication identified. Project team members who have been identified in project initiation are acquired (execution process); simultaneously their roles, responsibilities and authority levels are tailored to the specific need of the project. Project organization chart is developed and staffing management plan is defined.
2. There are three core roles in SCRUM development methodology: Product Owner, Scrum Master and Project team members.
3. Project Manager plays the role of Scrum Master in some companies, whereas in others Scrum Master report to project manager, who involved in overall set up of project management environment and accountable to achieve project objectives and in charge of all aspects of project. Project Manager is not a core role in SCRUM development methodology. PM serves as an escalation path after project team members, sprint leads, Scrum Master respectively.
4. It is the Product Owner responsibility to develop prioritized user stories (functional requirements with associated non functional requirements). Product Owner is accountable that project team deliver value to the business while Scrum Master is accountable to remove impediments to the ability of project team to define requirements and to deliver sprint goal. It is recommended not to combine role of Scrum Master and Product Owner.
5. Project team members are cross functional group of members who do actual analysis, construction, testing and delivery.
6. Here pre-assigned project team members are acquired so Scrum Master Involvement becomes critical even during requirement definition. Project team directory is developed. Project team building efforts are crucial at this beginning stage. Leadership is also crucial in beginning stage. Directing leadership style is mainly used during planning. Team building is carrying out to identify communication style of team members. For example if team member is collaborative and highly motivated then he/she can assign more responsibilities and his/het authority levels are adjusted accordingly as we know that team members operate best when their responsibilities match with corresponding authority levels. Note here I am assuming that project team members are acquired as per resources pre-assigned in project initiation. Other team members will be acquired later as identified and as per staffing plan.
7. Product Owner represents business and voice of customer. Product owner is assigned generally from the project team who better communicate with the customer to develop prioritize requirements which deliver value to customer and other stakeholders. Product Owner takes the services of assigned Scrum Master, project team members and other relevant cross functional stakeholders who involved in definition of product requirements.
8. Now first step is to defining and documenting stakeholders needs to meet project objectives. PMI says this as ‘Collect Requirement’ process and in agile this is release planning and result in Product backlog.
a. Project and product requirements are identified by progressively elaboration of project charter with the help of identified stakeholders included in stakeholder register. During requirement development identified stakeholders are involved and other also identified with the help of known stakeholders. Stakeholder register is updated accordingly.
b. When stakeholders are contacted during requirement document development their communication needs are also refined. Stakeholder’s skills, knowledge levels, interest levels are updated or identified for newly identified stakeholders. Project Manager performs this with the help of Scrum Master and Scrum Master performs this with the help of project team members.
c. Project team members and other relevant stakeholders including preferably customer are involved in facilitated workshops, where QFD is developed. Scrum Master facilitates the meeting. Customer needs are identified, these needs are objectively sorted, prioritize and goals are set to achieve them. Other tools are also used to identify quantified and documented needs of project and product requirements as defined in PMBOK 4.
d. Functional requirements and non functional requirements are identified. Functional requirements are features and functions of product, service or result. These are what part of requirements (Fitness for Purpose) and converted in use cases.
e. Non functional requirements like availability, security, performance are identified, which represents basis of determining how what part of identified requirements will be delivered (Fitness for Use). For more information on ‘Fitness for Purpose’ and ‘Fitness for Use’ please refer: http://seema-sonkiya.blogspot.in/2012/04/seema-sonkiya-pmp-project-quality.html
f. Whenever any impediments discover in requirement development mainly identified in daily stand up meeting, then Scrum Master is accountable to remove impediments and sometime converted into backlog item (product backlog in release planning and sprint backlog and some time product backlog during sprint execution or planning) for a structured attention from the team. In this way The impediments get equal attention from all related parties like Project Manager, PO, Scrum Master, Team, Customer etc
g. For each story non functional requirements are also identified like for Order use case it may be defined that it should be placed in less than one minute, some non functional requirements are also identified at project level like project should be usable even in peak hours.
h. User story is developed in high level preferably on story card. Keep story as small as possible. This story is refined during detailed design or during project scope statement development.
i. Acceptance criteria are developed from the analysis of use cases; at this time these are high level and refined in next process i.e. Project Scope Statement.
j. When a story is developed, team work to estimate it, we are in planning so that emphasis is to give estimation accuracy to +-10%. If story is not estimated with reasonable degree of confidence then it is communicated to Product Owner, preferably to communicate with customer to split it. Estimation should not be more than 3 development weeks otherwise Product Owner is asked to split the story with the help of customer if necessary. Estimation is performed in ideal day’s especially discrete efforts. User story development is discrete effort so estimation is always in ideal days.
k. A user story is valid if it can be estimated.
l. Product Owner assigns a priority value with the help of customer, QFD is used preferably to priorities story.
m. When requirement definition is complete and approved then it’s time to define iteration velocity which is influenced by release dates. Here we identify which requirements will be delivered in which release.
n. When QFD is used then core requirements are delivered first, then other needed featured and in last luxury features are delivered. Customer gets the priority in prioritization.
o. A meeting is called and customer is given a chance to review releases, and iterations.
p. Requirement development is completed and product backlog is key output as important artifact.
q. Product backlog is list of prioritized requirements and issues. Some impediments are also converted in prioritized requirements. Product backlog is owned by Product Owner, anybody anytime with the knowledge of product Owner can add to it, and only Product Owner can prioritize.
9. Next step is to define detailed project scope statement. Project scope statement is defined for the stories selected for next sprint means it is developed for the current sprint backlog.
a. Sprint planning meeting is performed.
i. In first part of sprint planning meeting product owner communicate the team what stories he/she want to complete in next sprint, project team then analyze how much of them they can commit. It is generally performed as per prior developed release planning as a result of QFD.
ii. Project team hashing out a plan and resulting in a spring backlog. Sprint backlog is list of selected user stories along with their associated non functional requirements. Sprint backlog is owned by the team and only team modifies it.
iii. Sprint goal is established, which is one sentence summary, declared by product owner and mutually accepted by project team members and product owner.
iv. Block list is updated regularly; these are the impediments, blocks and pending decisions. Owned by Scrum master and updated daily preferably are the discoveries of daily scrum. The impediments can come from anywhere, including requirements change, quality problems from customers, internal organization change, process change, technological blocks, etc. Therefore, for each impediment it’s important to define immediately “who” and “what”. Find an owner and define what needs to be done. The “done” part need not be an immediate solution to the impediment itself, but may be a way to handle it.
v. The advantages of treating impediments as part of backlogs are:
1. They become part of the process than exceptions
2. Team doesn’t have to switch gears often and the flow of sprint gets disturbed.
3. The impediment cycle aligns with the sprints
4. The impediments get equal attention from all related parties like PO, Scrum Master, Team, Customer etc. They get defined as what “Done” means as they’re backlogs.
5. They get properly unit tested and integration tested. The change for an impediment becomes incremental (which is the core of Agile Engineering).
6. A structured management of impediments can take the stress away from everyone involved.
b. During detailed scope definition we need to take in account:
i. Model with purpose.
ii. Keep multiple models to represent each aspect
iii. Travel light
iv. Content is more important than representation
v. Team members are co-located whenever possible to facilitate high quality of information exchange. Our emphasis is to get the team in performing team building stage. Team members can be easily confronted even in high conflict environment if team members are in performing stage.
vi. Keep things simple.
vii. Working software is primary deliverable.
viii. The best architecture, requirements and design emerge from self organizing team.
c. Project scope statement is the process of progressive elaboration of requirement documents for the selected stories for the sprint and corresponding information contained in project charter.
d. User story is refined from the story card.
e. Identify message flow in selected user stories. If we are concerned object life time creation then sequence diagram is developed. Sequence diagram generally capture single use case.
f. If we are concerned only for message communication then collaboration diagram is developed.
g. Class diagram is developed to represent static view of system. Dynamic view can be developed using flow charts if needed.
h. Complex class relation is explained using object diagram.
i. For complex code logic, activity diagram can be developed.
j. Finally project architecture is defined with the help of component and deployment diagram.
k. If complex design problem is encounter then an operation prototype is developed known as spike solution.
l. In agile design and construction are interleaved and we need to decide how much design is necessary before construction to prove the design. Detailed class design as per selected design patterns can be defined during execution processes.
m. Project scope statement is approved which is defined in greater level of details for selected user stories and future requirements are still in high level.
n. Make or Buy decisions can be refined at this stage.
10. Risk management plan is developed with the help of project scope statement, cost management plan, schedule management plan (management plans), communication management plan and taking into consideration of enterprise environmental factors and organization process assets.
11. At the same time WBS creation is stared, It forces to explore all aspects of project further. WBS is decomposed to work package level for the selected project work and other future work is still decomposed to milestone level. WBS is finalized by establishing control accounts for work packages.
12. WBS dictionary is developed
13. Scope baseline is finalized.
14. Once we have scope baseline, risk identification is performed with key input as scope baseline, risks are prioritize and response plans are generated. Product backlog and/or sprint backlog may be updated as a result of risk response planning. Scope baseline is updated.
15. Schedule is developed for the current sprint. Here I would like to point that as agile promotes self organization and sprint backlog is owned by project team, everyone has common understanding of work, so work allotment is done after consideration of work dependency (dependency between tasks affect pattern and usage of resources.), resource availability, skills and competencies and at last resource interest level are considered. We should not impose work to team members; work is assigned after analysis of their interest and motivation level after consideration of work dependencies, resource availability for the activity(s) period, skill and competency levels.
a. Please refer http://seema-sonkiya.blogspot.in/2012/03/project-schedule-development-important.html for the detailed schedule development.
b. Here I would like to add that for the functional requirements lowest level of WBS may represent use cases and these use cases may be decomposed to set of scenarios as activities.
c. We have developed project scope statement so duration estimate accuracy may be definite that is -5 to 10%, and as a result cost estimation accuracy may also go to definite as cost estimation is highly influenced by the resource assigned and the duration for which they are assigned. Range of estimate decrease so risk also decreases and contingency reserves are included in duration estimates for the risk remaining after risk mitigation. Please note after scope development we have done risk planning processes and we have developed risk responses. Risk identification repeated after estimation of duration of activities and after setting priorities response plans are generated. Scope baseline is updated to accommodate to risk response plans.
d. During schedule development new resource requirements may be generated and human resource planning, acquire human resources, develop and manage project team processes are repeated. Whenever new members are added to project, WBS is useful tool to see team members their roles. New team members should be allowed to understand work.
16. Project Cost and budget is established. For more information please refer http://seema-sonkiya.blogspot.in/2012/03/project-estimation-important-notes.html
17. We have all 3 baselines and risk and stakeholder register so Plan Quality is performed. For more information please refer http://seema-sonkiya.blogspot.in/2012/04/seema-sonkiya-pmp-project-quality.html
18. Pair partner is selected, for optimum use of resources two developer may share one pair partner. Pair partner is mainly does the code review as per approved coding standard.
19. Unit test and acceptance test cases are generated. Acceptance test cases may be refined during execution processes as more is known about the work
20. Project iteration even for same sprint is performed as a result of quality and risk response planning.
Execution and Monitoring Processes:
1. Work is executed for current approved project management plan including approved change request. Monitoring and controlling is performed throughout the project.
2. Sprint development is time boxed, work should be completed and unit tested on time, and anything remaining is left out and returned back to product backlog.
3. Refactor the work.
4. Completed work is submitted to Quality control process to identify causes of poor work and to validate deliverables. White box test cases and acceptance test cases are used to validate.
5. Burn down chart is updated daily to show pattern or history of variation and visual representation of outstanding work.
6. Earn value reports are generated. Corrective actions are identified as per established control limits.
7. Continuous integration is performed; pair programmers have the responsibility for continuous integration. Continuous integration is helpful to avoid compatibility and interfacing problems.
8. Completed work is demonstrated to users. Sprint review and sprint retrospective meetings are performed. Sprint review meeting is performed as part of Verify Scope process.
9. Sprint planning meeting is repeated after iteration imitation (like phase initiation to analyze whether project is on track to deliver business benefits).
Seema Sonkiya
Have to say that It´s a great article for those who, like me, are currently facing projects with the daily ambiguity of Agile and PMBOK. Keep posting please! ;)
ReplyDeleteRegards,
Christian Desideris Veron
Thanks Christian!!
DeleteWe need more of these scenarios to better understand and implement Agile methodologies by a Project Manager.Thanks Seema.
ReplyDeleteThank you very much Samarjit for your comment!!!
DeleteGood and helpful article.
ReplyDeleteThanks Seema
Thanks Sajan for liking my article!!
DeleteThanks Seema. Your articles are very helpful going into interesting details relating to real life experience. I look forward to your future posts.
ReplyDeleteThanks Lubo!!
Delete