Project Management
Project Management Processes, Process Groups and Knowledge areas
Project management as explained by PMBOK (Project Management Body of Knowledge) is accomplished by the appropriate application and integration of 42 logically grouped project management processes. These processes are spread across 5 process groups and 9 knowledge areas.
The five process groups are:
1. Initiating
2. Planning
3. Executing
4. Monitoring & Controlling
5. Closing
The nine knowledge areas are:
1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resources Management
7. Project Communication Management
8. Project Risk Management
9. Project Procurement Management
The processes that belong in each process group, what they do and which knowledge area they represent can be confusing. This post (based on the info in PMBOK) discusses about each process group and briefly explains the processes that belong in each process group. The knowledge area they represent is indicated in brackets after the process. This post could serve as reference for project managers and also help someone preparing for PMP certification.
Initiating:
Processes performed to define a new project or a new phase of an existing project.
● Develop Project Charter (Integration): Process of developing a document that formally authorizes a project and documenting initial requirements that satisfy the stakeholders needs and expectations. Output: Project Charter
● Identify Stakeholders (Communication): Process of identifying all people or organizations impacted by the project and documenting relevant information regarding their interests, involvement and impact on project success.Outputs: Stakeholder register, Stakeholder management strategy
Planning:
Processes required to establish the scope of the project, refine the objectives and define the course of action required to attain the objectives of the project.
● Develop Project Management Plan (Integration): Process of documenting actions necessary to define, prepare, integrate and coordinate all subsidiary plans. Outputs: Project Management plan.
● Collect requirements (Scope): Process of defining and documenting stakeholders' needs to meet the project objectives. Outputs: Requirements documentation, requirements management plan and requirements traceability matrix
● Define scope (Scope): Process of developing a detailed description of the project and product. Outputs: Project scope statement, project document updates
● Create WBS (Scope): Process of subdividing project deliverables and project work into smaller, more manageable components. Outputs: WBS, WBS dictionary, scope baseline, project document updates (WBS - Work Breakdown Structure)
● Define activities (Time): Process of identifying the specific actions to be performed to produce the project deliverables. Outputs: Activity list, activity attributes, milestone list
● Sequence activities (Time): Process of identifying and documenting relationships among the project activities. Outputs: Project schedule network diagram, project document updates
● Estimate activity resources (Time): Process of estimating the type and quantities of material, people, equipment, or supplies required to perform each activity. Outputs: Activity resource requirements, resource breakdown structure, project document updates
● Estimate activity duration (Time): Process of approximating the number of work periods needed to complete individual activities with estimated resources. Outputs: Activity duration estimates, project document updates
● Develop Schedule (Time): Process of analyzing activity sequences, durations, resource requirements and schedule constraints to create the project schedule. Outputs: Project schedule, schedule baseline, schedule data, project document updates
● Estimate costs (Cost): Process of developing an approximation of the monetary resources needed to complete project activities. Outputs: Activity cost estimates, basis of estimates, project document updates
● Determine budget (Cost): Process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline.Outputs: Cost performance baseline, project funding requirements, project document updates
● Plan quality (Quality): Process of identifying quality requirements and/or standards of the project and product and documenting how the project will demonstrate compliance. Outputs: Quality management plan, quality metrics, quality checklists, process improvement plan, project document updates
● Develop Human Resource plan (Human Resource): Process of identifying and documenting project roles, responsibilities and required skills, reporting relationships and creating a staffing management plan. Output: Human Resource Plan
● Plan communications (Communication): Process of determining project stakeholder information needs and defining a communication approach.Outputs: Communication management plan, project document updates
● Plan risk management (Risk): Process of defining how to conduct risk management activities for a project. Output: Risk Management plan
● Identify Risks (Risk): Process of determining which risks may affect the project and documenting their characteristics. Output: Risk register
● Perform Qualitative risk analysis (Risk): Process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact. Output: Risk register updates
● Perform Quantitative risk analysis (Risk): Process of numerically analyzing the effect of identified risks on overall project objectives. Output:Risk register updates
● Plan risk response (Risk): Process of developing options and actions to enhance opportunities and to reduce threats to project objectives. Outputs:Risk register updates, risk contract related decisions, project management plan updates, project document updates
● Plan procurements (Procurements): Process of documenting project purchasing decisions, specifying the approach and identifying potential sellers. Outputs: Procurements management plan, procurements statement of work, make-or-buy decisions, procurement documents, source selection criteria, change requests
Executing:
Processes performed to complete the work defined in project management plan to satisfy the project specifications.
● Direct & Manage project execution (Integration): Process of performing the work defined in the project management plan to achieve the project's objectives. Outputs: Deliverables, work performance information, change requests, project management plan updates, project document updates
● Acquire project team (Human Resource): Process of confirming human resource availability and obtaining the necessary team to complete project assignments. Outputs: Project staff assignments, resource calendars, project management plan updates
● Perform quality assurance (Quality): Process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards are used. Outputs: Organization process assets updates, change requests, project management plan updates, project document updates
● Develop project team (Human Resource): Process of improving the competencies, team interaction and the overall team environment to enhance project performance. Outputs: Team performance assessments, enterprise environmental factors updates
● Manage project team (Human Resource): Process of tracking team member performance, providing feedback, resolving issues and managing changes to optimize project performance. Outputs: Enterprise environmental factors updates, organization process assets updates, change requests, project management plan updates
● Distribute Information (Communication): Processing of making relevant information available to project stakeholders, as planned. Output:Organization process assets updates
● Manage stakeholder expectations (Communication): Process of communicating and working with stakeholders to meet their needs and addressing issues as they occur. Outputs: Organization process assets updates, change requests, project management plan updates, project document updates
● Conduct procurements (Procurements): Process of obtaining seller responses, selecting a seller and awarding a contract. Outputs: Selected sellers, procurement contract award, resource calendars, change requests, project management plan updates, project document updates
Monitoring & Controlling:
Processes required to track, review and regulate the progress and performance of the project.
● Monitor & Control project work (Integration): Process of tracking, reviewing and regulating the progress to meet the performance objectives defined in the project management plan. Outputs: Change requests, project management plan updates, project document updates
● Perform Integrated Change control (Integration): Process of reviewing all change requests, approving changes and managing changes to the deliverables, organization process assets, project documents and project management plan. Outputs: Change requests status updates, project management plan updates, project document updates
● Verify scope (Scope): Process of formalizing acceptance of the completed project deliverables. Outputs: Accepted deliverables, change requests, project document updates
● Control scope (Scope): Process of monitoring the status of the project and product scope and managing changes to the scope baseline. Outputs: Work performance measurements, organization process assets updates, change requests, project management plan updates, project document updates
● Control schedule (Time): Process of monitoring the status of the project to update project progress and managing changes to the schedule baseline.Outputs: Work performance measurements, organization process assets updates, change requests, project management plan updates, project document updates
● Control costs (Cost): Process of monitoring the status of the project to update the project budget and managing changes to the cost baseline.Outputs: Work performance measurements, budget forecasts, organization process assets updates, change requests, project management plan updates, project document updates
● Perform quality control (Quality): Process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. Outputs are quality control measurements, validated changes, validated deliverables, organization process assets updates, change requests, project management plan updates, project document updates
● Report performance (Communication): Process of collecting and distributing performance information including status reports, progress measurements and forecasts. Outputs: Performance reports, organization process assets updates, change requests
● Monitor and control risks (Risk): Process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks and evaluating risk process effectiveness throughout the project. Outputs:Risk register updates, organization process assets updates, change requests, project management plan updates, project document updates
● Administer procurements (Procurements): Process of managing procurement relationships, monitoring contract performance and making changes/corrections as needed. Outputs: Procurement documentation, organization process assets updates, change requests, project management plan updates
Closing:
Process performed to finalize all activities across all process groups to formally close the project or phase.
● Close project or phase (Integration): Process of finalizing all activities across all of the project management process groups to formally complete the project or phase. Outputs: Final product, service or result transition, organization process assets updates
● Close procurements (Procurement): Process of completing each project procurement. Outputs : Closed procurements, organization process assets updates
Reference: A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition
This PMP cheat sheet is a follow up to my earlier post on PMP formulas cheat sheet. I've gathered these as I've prepared for the exam and posting it here so that others preparing can benefit from it.
Questions:
1. What is a project?
2. What is a program?
3. What is a portfolio?
4. Who are stakeholders?
5. Define stakeholder characteristics?
6. What is contingency reserve?
7. What is management reserve?
8. What is last step in project closing?
9. How will you choose a project given NPV of many projects?
10. What is value engineering?
11. Who issues project charter?
12. What type of contract is purchase order?
13. Sensitivity analysis is a technique in which process?
14. Name some techniques in Perform Quality Assurance?
15. What is Kaizen approach?
16. Quality is management problem is mentioned by?
17. Zero defects/Do it first time is mentioned by?
18. Components of decision tree?
19. What is critical chain?
20. What is constructive change?
21. What is code of accounts?
22. Difference between precision and accuracy?
23. Difference between quality and grade?
24. Difference between agreement and contract?
25. Difference between product scope and project scope?
26. What is free float?
27. What is total float?
28. What is project scope statement?
29. How to interpret control chart?
30. What is staffing management plan?
31. What is resource histogram?
32. What is pareto chart?
33. What is workaround?
34. What is control account?
35. What are types of contracts?
36. List some information gathering techniques used in identifying risk?
37. Define Time and Material contracts?
38. What are seven basic tools of quality?
39. What are different types of conflict management techniques?
40. What are ways to handle negative risks?
41. What are ways to handle positive risks?
42. What are different stages of team development?
43. What is Maslow's hierarchy of needs (from bottom to top)?
44. List different types of power?
45. Which power is very effective?
46. Mention some sources of conflicts?
47. What is procurement audit?
48. What is gold plating?
49. What is point of total assumption?
50. What is war room?
51. What is the sequence of actions that should happen when an issue happens?
52. What is scope baseline?
53. What is marginal analysis?
54. What is zero sum reward system?
55. What is murder board?
56. What is oligopoly?
57. What is Ethnocentrism?
58. What is force majeure?
59. What is typical duration range for WBS activity?
60. What are responsibilities of risk owner?
Answers:
1. Project is temporary endeavor undertaken to create unique product, service or result (has defined start and end date)
2. Program is group of related projects
3. Portfolio is group of projects or programs (may or may not be dependent). They are grouped together for effective management.
4. Stakeholders are persons or organizations whose interests may be positively or negatively affected by the performance or completion of the project. Stakeholders include project team as well.
5. The stakeholders of a project typically have conflicting objectives. They have maximum influence during initial stages of the project.
6. Contingency Reserve is to cover known unknowns (known risks)
7. Management Reserve to cover unknown unknowns (unknown risks)
8. Last step in project closing is gather lessons learned and archive project info (Organization Process Assets updates) for future use
9. Choose project with high NPV (i.e high net present value)
10. Value engineering is less costly method to deliver same scope without performance degradation
11. Project sponsor issues project charter
12. Purchase order is fixed price type contract
13. Sensitivity analysis is a technique in Quantitative Risk Analysis
14. Quality audits, process analysis (includes root cause analysis) are some techniques in Perform Quality Assurance
15. Kaizen approach is Continuous improvement
16. Quality is management problem is mentioned by Deming
17. Zero defects/Do it first time is mentioned by CrosbySquare - Decision node, Circle- Chance node, Triangle - end of branch.
18. Decision tree components are square - decision node, circle- chance node and triangle - end of branch.
19. Resource constrained critical path is critical chain.
20. Undocumented change to contract is constructive change.
21. Code of accounts is numbering system used to uniquely identify each component of the Work Breakdown Structure (WBS).
22. Precision is values of repeated measurements are clustered and have little cluster. Accuracy is measured value is close to true value.
23. Quality is degree to which a set of inherent characteristics fulfill requirements. Grade is category assigned to products or services that have the same functional use but different technical characteristics. Low quality is not acceptable, but low grade may be acceptable.
24. Agreement is not legally binding but a contract is legally binding.
25. Product scope means the features and functions of the product or service being built. Project scope means the work that's needed to build the product.
26. Free float is time that an activity can be delayed from it's early start date without delaying early start of any immediately following schedule activities.
27. Total float is time that an activity can be delayed from it's early start date without delaying the project finish date.
28. Project scope statement contains deliverables and also the work required to create those deliverables.
29. Process is considered out of control when a data point in control chart exceeds control limit or if seven consecutive points in control chart are above or below (i.e on one side) of the mean.
30. Staffing management plan adds time (schedule) component to Human Resource (HR) plan. It also includes rewards and recognitions, training requirements and release criteria.
31. Resource histogram is part of staffing management plan. It describes the type and quantity of resources needed over a period of time.
32. Pareto chart is type of histogram ordered by frequency of occurrence. It shows how many defects were generated by type of category of identified cause.
33. Workaround is response to negative risk event. Differs from contingency plan in that workaround is not planned in advance.
34. Control account is management control point where scope, cost and schedule are integrated and compared to the earned value for performance measurement.
35. Different types of contracts are Fixed Price, Cost-Reimbursable, Time and material.
36. Information gathering techniques used in identifying risk are Brainstorming, Interviewing, Delphi technique and root cause analysis.
37. T&M contracts are hybrid type of contractual agreements that could contain aspects of both cost-reimbursable and fixed-price type arrangements.
38. Seven basic tools of quality are Cause and Effect (Fishbone or Ishikawa) Diagrams, Control Chart, Flowcharting, Histogram, Pareto Chart, Run chart and Scatter Diagram.
39. Conflict management techniques are Withdrawing/Avoiding, Compromising, Smoothing, Forcing, Collaborating and Confronting/Problem Solving,
40. Ways to handle negative risks are Avoid, Transfer, Mitigate and Accept.
41. Ways to handle positive risks are Exploit, Share, Enhance and Accept.
42. Different stages of team development are Forming, Storming, Norming, Performing and Adjourning.
43. Maslow's hierarchy of needs from bottom to top are Physiological needs, safety needs, social needs, self esteem needs and self actualization needs.
44. Different types of power are Reward power, Coercive (penalty) power, Legitimate power, Referent power and Expert power.
45. Most effective power is Expert power.
46. Resources, schedules and priorities cause 50% of project problems and conflicts. Schedule is the biggest source of conflict.
47. Once you've closed out a procurement, it's important to conduct a procurement audit. This is where you go over everything that happened on the project to figure out the lessons learned, and look for anything that went right or wrong.
48. Gold plating is when the team adds more work to the project that was not requested by the sponsor or client. It is not scope creep.
49. The point of total assumption is the point at which the seller assumes the costs. In a firm fixed price contract, this is the point where the costs have gotten so large that the seller basically runs out of money from the contract and has to start paying the costs.
50. The room the co-located team meets in is called a war room.
51. When an issue happens, analyze impact of issue -> submit change request -> if approved, update schedule and scope baselines -> implement the change.
52. The scope baseline is made up of Project Scope Statement, WBS and the WBS Dictionary.
53. Marginal analysis - The best level of the quality is reached at the point where the incremental revenue being gained from improvements equals the incremental cost being spent to secure it.
54. A Zero Sum reward system is a win-lose recognition program. For example, with an employee of the month program their will only be one or two team members who will win the award each month. Reward programs should be more win-win.
55. Murder board is a process where a committee asks questions from project representatives as part of the project selection process.
56. Oligopoly - There are few sellers and action of one seller will have impact on other sellers prizes.
57. Ethnocentrism refers to belief that ones culture is superior to other cultures.
58. Force majeure is a powerful and unexpected event, such as hurricane or other disaster.
59. WBS activity should be between 8 and 80 hours.
60. Every risk should have a risk owner listed in the register. That person is responsible for keeping the response plan up to date and make sure the right actions are taken if the risk does occur.
PMP Formulas Cheat Sheet
Recently, I took PMP certification. I'm posting the formulas that I had gathered during preparation in my personal cheat sheet, so that others preparing can benefit from it.
Three point estimate (PERT) = (to + 4tm + tp) / 6 (This applies for both cost and time) (to is optimistic estimate, tm is median estimate and tp is pessimistic estimate)
Standard deviation = (p-o)/6(p is pessimistic and o is optimistic)
Total standard deviation (given other std deviations) is sqrt of the sum of the individual variances (variance is square of deviation)
Schedule variance: SV = EV - PV (EV is Earned Value, PV is Planned Value)
(Note that SV is always 0 at the end of the project (if the project is completed))
Cost variance: CV = EV - AC (AC is Actual Cost)
(CV at the end of the project is AC - BAC) (BAC is Budget At Completion)
(Both SV and CV should be positive. Negative schedule and cost variance means project is behind schedule and over budget respectively)
Schedule Performance Index: SPI = EV/PV
Cost Performance Index: CPI= EV/AC
(Both SPI and CPI should be greater than 1. Schedule and cost performance index less than 1 means project is behind schedule and over budget respectively)
Burn rate = AC / EV = 1/CPI
Forecasting: (Estimate at completion - EAC)
EAC = AC + bottom up ETC (ETC is Estimate To Complete)
EAC = AC + (BAC - EV) - This is applicable if remaining work is estimate to continue at budgeted rate
EAC = BAC / CPI - This is applicable if remaining work continues at current cost
EAC = AC + ((BAC - EV)/ (CPI x SPI)) - This is considering both SPI and CPI
Variance at completion: VAC = BAC - EAC
Total Cost to Performance Index (TCPI):
TCPI based on BAC = (BAC - EV)/(BAC - AC)
TCPI based on EAC = (BAC - EV)/(EAC - AC) (Ratio of remaining work to funds remaining)
Expected Monetary Value: EMV = Probability X Impact (Cost)
Present Value: PV = FV / ((1+r) to the power of n) (FV is future value)
Ten tips for Conducting Effective Meetings
We all have been in meetings which are boring, too long, where other participants are poking their phones or even sleeping. This is partly because meetings are not conducted properly. Considering how many meetings we all attend every day, it is important to make meetings effective. Ineffective meetings could easily cost thousands of dollars to the organization (for ex, think about a team of 6 meeting several times a week ineffectively) Below are some of the tips that could help in conducting effective meetings:
1. Invite only relevant people to the meeting - It is important to invite only relevant people. Non-relevant participants either would not pay attention to meeting discussion or distract the meetings. They would be better off doing some real work.
2. Provide meeting agenda in meeting invite - This would help everyone to prepare for the meeting accordingly. This would also help participants to decide if the meeting is relevant for them and they can decide whether to accept or decline the invite accordingly.
3. Set up ground rules for the meeting - This needs to be done at the start of the meeting. This could be format of the meeting, behavior during the meeting, no use of cell phones etc., Ask if everyone is ok with this or if they want to add their own.
4. Discuss only things on agenda - During meetings, it is very easy to get distracted or get into too much details on one topic. Avoiding this or having the facilitator remind everyone when this happens is important so that meeting discussion is on track.
5. Have a good communication link - Having everyone co-located during meetings is very rare these days. Even if there is no off-shoring, we often work with other teams in US. Make sure you have a good phone line or better a good video-conferencing facility, if your organization can afford it.
6. Have short meetings - Short meetings are more effective. Attention span of participants might reduce as time goes by. 30 mins or 1 hour is a good time for meetings. If you need to have meetings beyond that, make sure you think about it and have a valid reason to do so.
7. End meetings on time - Even if you have short meetings, make sure that meetings ends on time. Participants might have something else scheduled after this and it is important to respect other people's time. Many participants tune out or think about the next thing they are going to do, once meeting goes past the scheduled end time.
8. Communicate results of the meeting - Conclude the meeting with results of the meeting and mention if any follow-up meetings are necessary. After the meeting, document (text, word, wiki etc.,) what was discussed in the meeting and send it to everyone (even to people who have missed the meeting). This would help participants to go back later on and find out what was discussed in the meeting. It could also serve as input for subsequent meetings.
9. Do not spread meetings throughout the day - Try to have meetings when team members are disturbed from their normal work anyway. Having back to back meetings or meetings concentrated in mornings or evenings leaves people some undisturbed time to work on their regular stuff. Programming needs concentration and every time people get disturbed, it takes time for them to get back on track.
10. Be a good facilitator - Being a good facilitator is key and can make even dull meetings fun. Having good communication skills, understanding of the subject etc., make meetings relevant. One of the key thing is to make everyone participate and make sure that no one's view is neglected. Facilitation skills are not easy for technical guys but is important to focus on.
I'm sure there are other points that would help too. If you want to add more, feel free to add them as comments.
My favorite tips from Pragmatic Programmer
I recently (finally) read the Pragmatic Programmer book and it has lot of good tips. Broken Windows and DRY are some of the widely known pragmatic programmer tips. Below are some of my personal favorite tips from this book:
1. Care about your craft - Care about the product that you develop and not just do it because you have to do it.
2. Don't live with Broken Windows - Make sure to fix bad designs, wrong decisions or poor code as soon as possible.
3. Be a catalyst for change - Like the stone soup story, it's time to bring out the stones. Show people what you got and how it could evolve in future and people will join you.
4. Remember the big picture - Don't be like boiled frogs. Be aware of what's going on around you.
5. Invest regularly in your knowledge portfolio - Just like managing a portfolio, we need to invest regularly, diversify it and manage the risks involved. Also, review and rebalance your technical portfolio in a regular basis so that it reflects the current trend.
6. DRY - Don't Repeat Yourself. Make sure that every piece of code has a single, unambiguos and authoritative representation in the system. Not that this also applies to documentation and not just for code.
7. Eliminate effects between unrelated things - We wants systems to be as orthogonal as possible. Less coupling allows them to change independently.
8. Don't program by Coincidence - Always know what you do and don't code blindfolded.
9. Test your software, or Your Users Will - It is better for the tester in your team to find issues before users find it. Better yet, make sure that you test your code and find any problem before the tester finds it.
10. Work with a user to think like a user - Don't just assume that users might need a feature just because it is in other apps, or it is cool or you like it. Work with a user (or product owner) to find out what they want and learn to think like them.
11. Refactor early, Refactor often - Always refactor to keep the code in good shape. Use the medical analogy of removing "growth", when explaining the need of refactoring to non-technical managers.
12. Don't be a slave to formal methods - Formal methods are good, but don't follow it blindly. It would be good to tweak it to suit your development needs and the team structure.
13. Don't use manual procedures - Always automate anything and everything that you do repeatedly manually.
14. Use Saboteurs to test your testing - Test cases or suites test our code. But, we also need to test the tests. Make sure that your tests produce alarm when they should.
15. Test state coverage, not code coverage - It is possible to fail with 100% code coverage. Make sure that all states of the system are tested well.
16. Find bugs once - When a bug is found, add test for the bug first and see it go red. Then fix it and watch it go green. Automated tests prevent the bug from happening again.
17. Sign Your Work - Take pride in what you do. Just like an artist signs their work, make sure to sign your code (ex - @author tag in Java) and take pride in the code your develop. Other developers should expect to see your name and expect it to be well written, tested and documented.
Success Tips for Agile Teams
We've been doing Scrum for few years now. I've also seen how our team and other teams do some of the common things which makes us less efficient. This post just talks about some of the things that I learned through Agile/Scrum training, Agile books, from our own experience and seeing/hearing other teams which do Scrum. Each point starts with what is good to do followed by (in brackets) how teams commonly do it now which makes it less efficient. Many of these were done by our team too, but we are trying to recognize the issues and improve them continuously.
1. Start with product vision and release objectives. Then do road map planning to define when each functionality is needed. It is important to share this with the team so that team understands the big picture and knows where they are heading to. (Some teams go from sprint to sprint heads down, which means the team may not understand the big picture.)
2. When release objectives are set, do release planning with the team and get commitment on what can realistically be delivered for the release. (Management could arrive at the deadline/feature list without consulting the team, which means it is not realistic. Having team commitment early on in the project is very important.)
3.
4. Product owner should do continuous backlog grooming and thin slice the user stories with the help from the team. (Avoid having big stories which are not flushed out properly)
5.
6. The focus of the sprint should be on maximizing delivering features which end users can use at the end of every sprint, even if it comes at a small cost of developer productivity. (The focus of the sprint should not be to manage the team's tasks and fully load the development team. Instead the focus should be on getting completely implemented user stories.)
7. The team should be well cross trained i.e anyone in the team should be able to take any tasks (as much as possible) to complete the sprint stories. For this to be successful, it is important to have a small team focused on a particular area. (Avoid having teams with too many specialists)
8. Team size including product owners and scrum master should be in single digit. (Think about breaking the team if your team size is in double digits)
9.
10. Sprints should be sustainable with each sprint including review, retrospective and planning taking the same amount of time. (Many sprint teams are so tired at the end of long hard working sprint. The focus should be on making the sprints enjoyable and sustainable. Also, avoid having irregular sprint lengths)
11.
12. The focus should be on conversation with product owners and recording the conversation as acceptance criteria for the story (confirmation), rather than writing long use case documents. This is based on famous three C's - Cards, Conversation and Confirmation. (Sprint teams should focus on face to face conversation rather than relying on long documents)
13.
14. User stories should be accompanied with good acceptance criteria so that team understands what done really means for that user story. (Not doing this is the root cause of many bugs. Having good acceptance criteria and shared understanding (between product owner, developer and tester) of when a story is really done would help a lot)
15.
16. Team should do collaborative planning and be empowered to do what it takes to deliver the sprint goals. Entire team should focus on how they can accomplish/commit to the sprint goals together. (Avoid too much focus on individual team member tasks. Instead focus should be on the delivering as a team)
17.
18. Estimating user stories in story points is better than doing in hours. (This could be unclear if the team does not have common understanding on what a story point is. Entire team should have common understanding of what a story point is and understand they are relative estimates.)
19.
20. When splitting user stories, try to split it vertically rather than horizontally i.e functionally rather than architecturally. (Developers have the natural tendency to break up a big user story into a) DB work b) DB API c) GUI work etc., Instead the user stories should be divided so that each user story delivers some meaningful functionality to the end user.)
21.
22. Use daily meetings as a way to communicate to other team members. (Do not use it as a way to report individual progress, which over time might become mundane and not liked by everyone in the team).
23.
24. Entire team should be committed to delivering the stories and delivering it completely. (Half/Almost done stories gives a false impression that they are done and also cause more bugs. Avoid it by not giving credit and don't use it's story points to count towards velocity.)
25. When the story is done, make sure it means it is both developed and tested completely (Often teams just do development and call it done, which means testing will be done later. This really means a story is not done, if testing finds major misunderstanding/bugs in the code)
26.
27. Team should plan on getting the user stories implemented and give it to testers as early as possible in the sprint. (Often teams might finish a story very late in the sprint, which makes it hard for it be tested and fix bugs (found during testing) before the end of the sprint)
28. Developers could do code reviews, work on infrastructure tasks, help with testing, learn more about the product, etc., if they are done earlier than anticipated. (Often teams pack the sprint which mostly means there is no time to do anything else)
29. Use retrospectives efficiently to find and fix issues which slows down the team. Make progress on these issues transparent so that team can understand that their concerns are handled properly. Continuous improvement is important to any team. (Many teams use it as a formality and not really do anything with the issues raised in retrospectives. This could make retrospective meeting not liked by team members)
I just mentioned some of the things which came to my mind. Feel free to add your comments here.
I mostly read online articles/blog posts to keep me up to date. I read books whenever I get a chance. Below are some of the books which I've read this year.
1. First, I finished reading the books I was in the middle of reading in 2009 -Programming Groovy and Eclipse - Building Commercial quality plugins. My comments about these books can be found from my last year's post.
2. Java Puzzlers - This is one of the classic java books written by Josh Bloch and Neal Gafter. It has lots of java puzzles which are very interesting and I learned a lot about the intricacies of the language from this book. If you think you know Java very well, try solving the puzzles in this book and it would make you rethink about it. I highly recommend this book to any java programmer and I'm sure everyone (even if you have lot of experience in Java) will learn new things about the language from this book.
3.
4. The Mythical Man Month - This is one of the classic books on Software Engineering and Project Management. This book was originally published in 1975 and republished with few more chapters in 1995, but almost all of the things explained in this book still hold good. The classic saying "9 women cannot produce a baby in one month" comes from this book and the author says this to explain that adding more programmers to a delayed project will not make it faster. Some of the ideas presented in this book are explained in the wiki page of this book. I highly recommend this book to any programmer, more so to anyone who manages a project, be it a Development Manager or Project Manager.
5. Design Patterns: Elements of Reusable Object-Oriented Software - I have been using design patterns in my code for several years now and mostly learned design patterns by reading online articles and blog posts. I have read this book on a on-demand basis in the past and always wanted to read it completely. Finally, got chance to read it completely this year and it was a good refresher to many of the design patterns and I also learned few new ones. I don't need to tell about this book, as it is a Classic Design Patterns book and is a must read for any programmer.
6. 97 things Every Programmer Should Know - This book is a collection of thoughts on things which every programmer should know and has many nice ideas and tips. If you are new to programming, I'm sure this book will open your eyes. Even if you are someone with several years of experience, I'm sure your time will still be well spent reading this book and you will learn useful things. You can also get an online version of the contributions appearing in this book.
7.
8. Agile Software Development with Scrum - This is a basic book on what Scrum is and explains the concepts very clearly. One of the authors of this book is Ken Schwaber, who is one of the co-founders of Scrum. I have been using Scrum more more than 3 years now and have been ScrumMaster for most of this time. I have read parts of this book few years back and so wanted to read it again and it made some of the things more clear to me. I highly recommend this book to anyone interested in Scrum. If you are thinking about starting to use Scrum, but not clear about it or it's benefits, then this is the book you need to read.
9. Kanban and Scrum - making the most of both - Kanban and Scrum are different Agile project management methodologies. This book explains about Kanban and Scrum - it's similarities and differences and how to use them together to get the advantages of both. You can get an online version of this book from InfoQ. You may have to register/sign-in first before downloading the book. I recommend this book to anyone who is using Scrum or Kanban or any other Agile management methodologies and is a must-read for any ScrumMaster.
10. Agile Retrospectives: Making Good Teams Great - This book is the bible for Agile Retrospectives and is written by Esther Derby, who is well known for her thoughts on improving retrospectives. This book presents many techniques on how to gather data and generate insights in a retrospective. It also presents ideas on how to decide which ideas to implement immediately. This book offers good advice on how to lead retrospectives and is a must read for anyone who leads the retrospectives, mainly for any ScrumMaster. We used some of the ideas presented in this book and they worked great. We also plan to use more techniques presented in this book in upcoming retrospectives.
Looking forward for a very exciting year 2011. Wish everyone a very Happy and Prosperous New Year!
Managing dependencies in Maven
Managing dependencies in Maven, particularly managing the transitive dependencies and versions of the dependencies used can sometimes become a daunting task. Thankfully, there are some maven plugins and other resources to help in this. Just thought of sharing them in this post.
1. Intro to maven dependency management - An intro to maven dependency mechanism can be found here (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html). This article gives an introduction about transitive dependencies, dependency scopes and dependency management in maven. This is a must read for any maven beginner.
2.
3. Maven dependency plugin - You can find the goals and documentation for it here (http://maven.apache.org/plugins/maven-dependency-plugin/). The goals that I use frequently are dependency:resolve(resolves the dependencies and displays the versions used), dependency:tree (resolves the dependencies and displays them in tree structure - an easy way to find out which dependency brings which transitive dependency etc.,), dependency:copy-dependencies (copies all the dependencies including transitive dependencies to a specified location). dependency:analyzecould be useful too.
4.
5. Maven versions plugin - You can find the goals and documentation for it here (http://mojo.codehaus.org/versions-maven-plugin/). The goals that I use frequently are versions:display-dependency-updates(tells which dependencies use the latest versions and which ones have newer versions available - could be very useful to see how stale your pom is), versions:use-latest-versions (searches pom for dependencies which have newer versions and replace them with latest version - could be useful to bulk update your pom to use latest version of all dependencies).
6. Maven Repository Browser - This is a website (http://www.mvnbrowser.com/index.html), which I just encountered today while trying to search for a missing dependency in my pom. POM report (http://www.mvnbrowser.com/pom-report.html) seems interesting. You can copy paste your POM or just the dependencies section and this would tell you what are the available versions for all dependencies in your POM and if you are using the latest one or not. It also lists what other dependencies are in your classpath. Seems like a simple UI version of what maven dependency and versions plugin does. Apart from this, it also lists the licenses involved. I have used this website very little as I just found it, but it seems useful.
I just mentioned the goals I use most. These plugins have many other useful goals as well, which you might want to explore. Try these maven goals in your maven projects and see for yourself the power of these maven plugins. Hope this post introduced you some new things to manage your maven dependencies and pointed you to some good resources.
Effective Leadership/Communication skills needed for a Manager
Recently, I got promoted to a development manager and being primarily a technical guy before, I'm trying to improve my leadership/communication skills. Below is my personal notes (gathered from various sources) on the qualities to possess to become a great manager.
1. Technical Subject knowledge - Need not be expert in all areas, but need to understand things well enough to make better decisions.
2.
3. Be assertive, not aggressive though.
4. Be cool under pressure.
5. Competent.
6. Integrity/Honesty.
7. Ability to delegate tasks.
8. Conduct meetings effectively (proper agenda, starting/ending on time, insisting full participation etc.,).
9. Empathy - Understand and relate to individual's issues.
10. Body language and tone is important (sometimes more than content).
11.
12. Tone is very important in meetings, conference calls and even on the email.
13. Smile (even on the phone) helps a lot.
14. Different people in the team want/appreciate different things. Need to understand that and communicate appropriately. There is no one way to communicate to a big diversified team.
15. Create a positive atmosphere for the team and promote collaboration.
16.
This list is not comprehensive by any means and just serves as a reminder/personal note to me at this point, so that I can improve in these areas. Just thought to add it as a post, in case it might help someone else. If you have other points, feel free to add comments.
Key Points for any Project (Traditional or Agile)
I'm using Scrum for the past 3+ years and have been ScrumMaster for most of this time. I embrace and advocate Scrum, but last week, I attended a FredPryor Seminar on project management, mainly to better understand the similarities and differences between traditional project management and Scrum. This also helped me in appreciating how basic project management skills applies to any industry. I want to highlight some of the common basic points which came up in the seminar, which are important irrespective of which methodology we are using.
1. Kick-off meeting is important when starting projects (or Sprint in Agile) - I see this as similar to Sprint Planning in Agile. Everyone involved need to get a clear idea on what they are building.
2.
3. Team buy-in from the very beginning is critical.
4. Brainstorming with the team on topics is important.
5. Everyone (Team, Management, Stakeholders) agreeing on specific, realistic goals is important.
6. Clear project definition and scope is very important. Avoid scope creep.
7. Be SMART when defining a project (or Sprint in Agile) - Specific, Measurable,Achievable, Realistic, Timely.
8. Risk Assessment - Understand constraints between Time, Cost and People. Often, when risk comes the trade-off is between one of these.
9. Progress - Gantt-Chart in traditional project management becomes Burndown chart in Agile (at least on the high level).
10. Meetings - Need to have team meetings on time, in regular schedule with a specific agenda. Full participation of team is important. Also, need to respect other's time and end the meeting on schedule. Finally, need to take meeting notes and follow up promptly.
11. Team working collaboratively is very important. This will create a co-operative and productive atmosphere.
12. Start the project with self-esteem and end it with self-esteem (for the team).
13. Always recognize the team and celebrate success.
14. Review all outstanding issues after the project (or Sprint in Agile) is done and see what can be improved - Similar to Sprint Retrospective.
I understand the differences between Traditional and Agile and how Agile improves the success of the project. But, still there are many basic things that apply to any project management methodology. Many of these seem like common sense, but if we think about it, lot of these are not being practiced in our day to day projects. I'm sure following these points will surely improve the success rate of any project. I just listed some of the points, which comes to my mind at this time. If you have other points, feel free to add comments.
ntroduction to the PMBOK® Guide
A Guide to the Project Management Body of Knowledge (PMBOK® Guide Fifth Edition)
● Key terms and the project life cycle
● Identifying External Environmental Factors (EEFs) and Organizational Process Areas (OPAs)
● Organizational structure and influences
Mapping the interrelationships of knowledge areas to process groups
● Outlining the five process groups
● Defining the nine knowledge areas
Project Integration and Scope Management
Identifying and integrating processes and activities
● Identifying a new project, business case and strategy
● Defining and coordinating all subsidiary plans
● Change-control and configuration management
Defining, verifying and controlling the scope
● Facilitating requirements-gathering using interviews, workshops and decision-making techniques
● Requirements changes and traceability matrices
● Determining scope through product analysis and Analysis of Alternatives (AoA)
● Creating the WBS through decomposition
● Setting the scope baseline and analyzing variances
Project Time and Cost Management
Time management
● Defining and sequencing activities
● Estimating activity resources and durations with analogous, parametric and three-point techniques
● Developing the schedule using PDM, ADM and CDM diagrams
Determining the cost baseline and applying Earned Value Management (EVM)
● Identifying costs and calculating performance baseline
● Assessing EVM key dimensions, variances and indices
● Forecasting with EVM
● Performance reporting
Project Quality Management
Implementing systems for quality
● Preventing nonconformance through Cost of Quality (CoQ)
● Performing continuous improvements
Tools and techniques to study
● Planning for quality using statistical tools
● Implementing quality metrics and audits
Project Human Resource, Communication and Procurement Management
Developing the plan and acquiring the team
● Creating hierarchical and matrix charts (RAM & RACI)
● Developing the team
● Reward and recognition
● Motivational theories
● Conflict resolution techniques
Managing the stakeholders through communication
● Analyzing stakeholders and their expectations
● Distributing information with communication models
● Applying communication theory and the levels of power
Procurement management
● Performing make-or-buy analysis
● Formally accepting the product and closing the project
Project Risk Management
Assessing project risks
● Qualitative and quantitative risk analysis
● Evaluating Expected Monetary Value (EMV)
Exam-relevant tools and techniques
● Developing threat/opportunity response strategies
● Reassessing and controlling risks
Planning for the Exam
Preparing for test day
● Applying proven tips for exam success
● Conquering exam apprehension
Personalizing your study plan
● Identifying your strengths and weaknesses
● Optimizing your study time and focus
Professional Responsibility and Ethics
● The PMI®Code of Ethics and Professional Conduct
● Balancing the interest of all stakeholders
0 Response to "Project Management"
Post a Comment