Business case and project charter confusion is not uncommon. They both have integral roles in the initiation of a new idea--but they should not be used interchangeably. At the end of day, the project sponsor is accountable for success--and is responsible for ensuring recommendations are held up by a sound business case.
Find answers to these questions and more in this Business Case Practice Area. If you are new to Business Case, take advantage of the resources below and don't be shy about commenting or asking questions. If you're a seasoned pro, help others out and become an influencer. We welcome contributions from all sources and the more you participate, the more visible you become. Let us help you move down the road from "giver of sage advice" to "Thought Leader".
What happens to a PM who is trying to adopt Agile? Dave Prior, PMP discusses the struggles you can expect to encounter while showing you how creating a Personal Agility Canvas tool can help make things a little easier.
Epistemology is a branch of philosophical and scientific inquiry that asks “how do we know what we know?”. The speaker is amazed how little this is asked in the majority of books, research papers and industry studies related to project management. The speaker will argue that this lack of inquiry and understanding is the cause of many project failures.
Managing quality during a software development project can be difficult and time consuming when you have been misinformed about true quality indicators and practices. Actively managing quality on an agile project can be both simpler and harder than traditional approaches. Here are some basic practices to save time and unnecessary rework--and improve stakeholder satisfaction before and after delivery.
Project managers need to communicate effectively with all types of project stakeholders. For agile projects, this sometimes involves adapting traditional PM constructs into the closest agile alternatives. Agile pendentives are adaptive patterns that facilitate these traditional-to-agile discussions.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
The number of agile certifications available in the market keeps growing, and one must consider the unique needs of the inquiring company or individual to know what would be best for them. What factors should you consider? Do you even know the options available?
Agile approaches often have greater engagement levels between stakeholders. While those conversations generally focus on the deliverables and how they meet the customer’s needs, can they also drive sustainability best practices?
Agile does not enforce rigid processes, but organizations typically choose a guiding framework and a set of practices that serve as the starting point of an agile transformation. Executives typically want to know where teams are in terms of adopting these new ways of working. This article provides three techniques--individual, team and group--that can be used to assess the agile adoption level, monitor progress and drive improvements.
Have you ever entered a sprint taking on a user story that you later regretted? What can be done to prevent this frustration? Is there a technique that will prevent this from happening, or are these teams doomed to keep repeating their mistakes?
Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer. So why the disagreement? How can smart, experienced people have such different views about the same topic?
How many of us start a project thinking that we understood the reason behind doing the project in the first place? There’s about half of us who never aligned the project’s mission with the overall department or company vision, resulting in poorly made decisions--and possibly a breakdown in team morale. Providing a project focus that supports a larger purpose is particularly important for fast-paced, adjusting agile projects.
Question: After a recent conversion by my team regarding agile, we find that there is a mismatch between the number of hours we should have for working on stories and the amount of time we really have. So we are constantly over-committing to our Product Owner and not delivering. Where are we going wrong?
Traditional teams may have a 15-20% contingency cushion in time and cost on their project estimates. Routinely subtract a similar agile contingency from the number of backlog items you accept to make sure you finish all planned work within a single iteration.
Agile is expected to be flexible, and velocity can vary. Just complete what you can and adjust your velocity for the next sprint if you don’t finish all of the stories you committed to complete this time.
Be sure you are acknowledging hours that team members will spend in Scrum ceremonies, personal time commitments and non-team directed organizational work before calculating the capacity for this iteration.
Ask the ScrumMaster to speak to anyone on the team who did not finish his or her work during the previous iteration. This person is making the team look bad and should be disciplined if it happens again.