This interview about why Agile might be failing in your organization with NK Shrivastava was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss his presentation and white paper Top Five Warning Signs That Agile is Not Working for You. Here are the abstract and conclusion:
Abstract: There are good possibilities of success when adopting an agile approach in an organization, but five symptoms in particular serve as warning signs that the organization’s agile transformation is not working well.
The five warning signs include: (a) no signs of value delivery for over 3 months, (b) teams resisting customer changes, (c) teams “waterfalling” sprints, (d) customers foregoing involvement in development and testing, and (e) lack of visibility for agile in the organization. Potential solutions for these problems are also described in this paper. Many organizations can solve these problems internally, but sometimes an external resource such as a change agent or an agile coach is needed. By addressing these issues, organizations can increase the chances of a successful agile transformation.
Conclusion: Agile doesn’t work by itself. Organizations that implement agile with minimal team support and expect it to work perfectly “out of the box” will likely be disappointed. Successful agile adoption depends on factors at the organization and team levels. Organizations need the right mindset, a strong commitment, a culture conducive to implement agile, and the ability to secure resources and outside help as needed. Teams need the training, skills, and empowerment to absorb and implement agile principles. With these factors in place, organizations and teams should be able to build the foundation for agile success.
Five Tips to Create a Work Breakdown Structure (WBS)
The Work Breakdown Structure (WBS) is the first step to create a project schedule. The WBS is used to uncover all the work. Understanding the project work, and the project management work, gives you a total picture of the project.
Use the following five techniques to create a solid WBS for your project.
Do Not Make the WBS Too Tall
If you envision the WBS being built with post-it notes on the wall, it is important that you not let the WBS get too tall (This could also be called "too deep"). Depending on your WBS approach, it may take you two to four levels to get the deliverables defined. The general rule of thumb is that the number of levels for each deliverable should not exceed five and even five might be too many.
Create a WBS Dictionary for Large Projects
Normally a dictionary would not be needed, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. If the WBS is very large, it might make sense to place all of the important information in a WBS dictionary. Once the WBS information is entered into a tool, the tool can also help to keep track of changes to the work so that you can trace how the change impacts the WBS and the schedule. Having the WBS in a tool also makes the information easier to reuse for future projects.
Use Your Summary Activities for Schedule Milestones
Summary activities are the ones that are broken down into more detail. Detailed activities are not broken down further. When you create your schedule, you should only include the detailed activities, not the summary ones. For the sake of clarity and readability, it often makes sense to include these higher-level summary activities in the schedule to represent a logical roll-up of the detailed activities. A summary activity that represents the completion of a major deliverable could also be included in the schedule as a milestone.
Break Summary Activities into Two or More Detailed Activities
Since you chose to break a summary activity into smaller activities, it does not make sense to only have one detailed activity under a summary one. If you do, the detailed activity represents the exact same work as the summary activity. This does not buy you anything. If you are going to break work down into a lower level, make sure you always identify two or more items at the lower level.
The Detailed Activities Should be Written as Action Oriented Activities
The detailed activities on your activity-based WBS are ultimately moved to the schedule. For that reason, it is easier if the detailed activities in your WBS are action oriented – just as activities in your schedule would be. For example instead of stating a detailed WBS activity as “conference”, you should state it as “organize a conference”, or “attend a conference”.
WBS's are interesting structures that serve as the backbone for creating a schedule. There are many more techniques as well, but these five provide a good starting point.
Click here to listen to our Best PM Podcast episode for today: http://bit.ly/PMPodcast_361
23,918 project managers have listened to it so far!
Leadership in project management is an important topic these days. And if you are like most project managers then you may have fallen into project management a bit by accident. And then, after you have successfully delivered a few projects, suddenly everyone tells you that you must improve your project management leadership skills.
Effective project management, they say, depends a lot on your project leadership.
And so once you realise that you have to transform into a project leader then leadership training will be part of your ongoing professional development, which is where our guest can help.
Niraj Kumar (www.leadproje.com -- http://www.linkedin.com/in/thenirajkumar) is a leadership expert and proponent of self-growth through continuous learning. Together we explore his view on leadership, how these skill help you as a project manager, how they help you when dealing with senior executives, and as always we include a lot of tips on how you yourself can improve how you approach project management and leadership starting today.
Define These Twelve Sections in a Full Project Charter
The detailed Project Charter holds the information that you uncovered in the project definition process. The Project Charter is written by the project manager and approved by the project sponsor to show that there is an agreement on the work to be completed. (Click here for a free Project Charter.) The information in the Project Charter typically includes:
1. Project Overview. State the purpose of the project. Discuss the business benefit of the project and share the overall business goals that this project is helping to achieve.
2. Project Objectives. List the objectives that the project will achieve. The project objective should support your organization business goals and strategies. The deliverables produced should support the project objectives.
3. Project Scope. There are two parts to the scope section - deliverables and boundary statements. For each deliverable, provide a high-level description. It is very important to be clear about what things the project could produce, but will not. This will make it much easier to manage scope change throughout the project.
In addition to deliverables, you should also state any project boundaries. It is a good practice to state scope boundary conditions in terms of both in-scope and out-of-scope statements.
4. Estimated Effort Hours (resources). Estimate the effort required, and provide information on how the estimate was prepared.
5. Estimated Duration. Once the effort hours are known, you can estimate how long the project will take to complete (duration) based on an assumption of how many resources will be applied.
6. Estimated Cost. Estimate the cost for labor based on the effort hours, and add any non-labor expenses such as equipment, supplies, training, travel, etc.
7. Major Assumptions. Assumptions are statements that you believe to be true but you are not 100% certain. Assumptions can be identified through your own experience, brainstorming sessions with the stakeholders; and by looking at items that were identified as low risk in the risk management process.
8. Major Risks. There may be future external conditions or events that will cause problems to the project if they occur. These are listed as risks if the combination of probability and impact are not acceptable.
9. Constraints. Constraints are events or limitations that are outside the control of the project team and need to be managed around. They are not necessarily problems. They are not risks since they are 100% likely to occur. They are facts.
10. Project Dependencies. List any other projects that are in progress or pending that have a dependency with your project. These dependencies are deliverable-based. Don't consider a project to be dependent simply because you might share a resource with it.
11. Project Approach. You should describe major project phases and milestones, and the general sequence of the work. Also take some time to explain any interesting or out-of-the-ordinary techniques that will be utilized on the project.
12. Project Organization. The organization chart has boxes that reflect involvement from various stakeholders. List the project manager, sponsor, project team, steering committee, etc.
The Project Charter describes the nature of the project and what you will build. The project schedule tells you how you will produce the deliverables.
We continue our look at the topic of scaled agile that we started in the previous episode, this time by looking at "agiLE" - Agile in the Large Enterprise.
This interview about Scaling Agile with Joy Beatty, PMI-PBA was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss her presentation and white paper Making "agiLE" Work: Agile in the Large Enterprise. Here are the abstract and final thoughts:
Abstract: Almost all large enterprises are making some transition to agile practices. There are many approaches to scale agile in the large enterprise, and we’ll give an overview of the most common scaled approaches and their limitations. This paper also discusses the most common challenges our customers’ teams are facing when scaling agile and provides suggestions to overcome those challenges.
Final Thoughts: This sounds like a daunting task—to transition to agile approaches in a large organization. However, with solid collaboration and communication, it’s absolutely doable. Teams will constantly be collaborating through elicitation, answering questions, and testing the actual product. Business analysts have a critical role to play in keeping the collaboration running smoothly, including helping to facilitate backlog grooming and elaboration, participating in planning in sprints, working with interfacing teams to identify dependencies, and serving as a product owner proxy on any teams as needed. Likewise, project and program managers can act as advisors about appropriate levels of process, help guide projects toward common goals, and ensure a focus on prioritization based on business needs. Instead of instilling a hierarchical control between PMO and product owner, in agiLE the PMO and product owner work together to achieve the objective. The real goal for agiLE teams is self-organization and creativity, while still contributing as a part of a large organization