Information radiators can help stakeholders remain informed and can reduce effort spent by a team in handling requests for updates but to reap these benefits we must ensure that the information published meets their needs.
As with any type of communication, if the content published cannot be trusted due to obvious inaccuracies or a lack of currency, stakeholders will cease to consult the radiators and will demand that traditional reporting methods are re-established.
Such defects will also reduce the credibility of the team in the eyes of the stakeholders.
This is one more reason to ensure that if Kanban boards or other work visualization views are made accessible to stakeholders outside a delivery team that team members are diligent in updating them while work is being done rather than after the fact.
If an information radiator generates more questions than it answers, it will become a burden for the delivery team. Not only does this mean that legends, titles, and thresholds are clearly presented, but it also requires that any information which could be misinterpreted should be accompanied with some context so that stakeholders get the correct story.
For example, if a sprint burn down chart is being published daily and by the midpoint of the sprint it appears that very little has been completed, a stakeholder might reasonably assume that the team is going to complete significantly less than what had been agreed to during sprint planning. However, if some context is provided that the team's delivery process includes an independent review by an external inspector who is only available one or two days per sprint, this apparent lack of progress might be perfectly acceptable.
This also means that we should review what is being published to ensure that stakeholders can perceive the forest as well as the trees.
Publishing a sprint burn down chart or Kanban board without providing a team's Definition of Done is only part of the story. Posting a release burn up chart without indicating what is being delivered in the release will not promote shared understanding.
Finally, it's important to educate stakeholders so they can effectively pull information from the information radiators and to set expectations that radiators are to be consulted as the first source for updates.
Poor information radiators are a constant reminder of George Bernard Shaw's caution that "The single biggest problem in communication is the illusion that it has taken place."
Do PMOs still add value in organizations that are at a high degree of project management maturity?
A LinkedIn question on the topic of PMOs in the future made me think about the benefits of having a PMO once a company has reached a high degree of project management maturity. This is not as fantastic a vision as you might think – after all, PMI’s tag line used to be Making Project Management Indispensable For Business Results and it is not outside the realm of possibility that many organizations will (at some point in the future) have project management institutionalized as an organizational competency instead of a skill shared by a select few.
When such a time arrives (See, I can take a “glass is half full” position at least once every year!), will there still be a need for a PMO? After all, if project management skills become as natural to staff as operational competencies, do we still have a need for a group focused on the discipline?
The first analogy I would make is to quality. Even those companies that have reached stratospheric altitudes of quality and have embedded this competency into all aspects of their organization would still have a staffed quality department.
Here are some of the benefits that a PMO can provide to higher maturity companies:
No matter how good a professional golfer is, they will usually benefit from a coach to help them maintain their performance and to improve. An effective PMO will still be a valuable coach to your organization no matter how low your project management handicap goes!
(Note: this article was originally published by me in July 2012 on my personal blog, kbondale.wordpress.com)
Many project managers have doubtless exclaimed “giving birth would be simpler than managing this project”! This may be truer than they ever imagined…
Initiation can provide the same euphoria as finding out you are going to be a new parent – getting assigned to a new project is an exciting but also unnerving time. There are hundreds of questions, but also plenty of stakeholder input! There are myriads of sources of information, but it can be challenging to separate the useful lessons learned from “old wives tales”!
Planning can prove to be as unpleasant as the first trimester – with frustrating stakeholders, challenging constraints, uncertain scope and storming teams, project managers might be excused for acting as though they suffer from prolonged morning sickness! With appropriate attention & resourcing combined with a healthy dose of risk management, the project manager should strive to lay a solid foundation for the rest of their project/pregnancy.
Project execution can feel a lot like the second and most of the third trimesters. This is where the (literally) heavy lifting takes place, the peak resourcing/food intake, and careful monitoring & tracking of vitals, but if planning was done well, it should be a fairly smooth ride. Resource shortfalls need to be addressed in a timely fashion to avoid impacting the project’s outcomes and cutting corners on quality will come back to haunt you long after the project/baby has been delivered! While change is to be expected, it should not be rushed into without appropriate governance. The need to prepare the environment for the impending arrival is also crucial. Procrastination on implementing effective organization change management will be extremely costly as anyone that has had to decorate a baby nursery at the last minute will attest!
Finally, project closeout can range from the very smooth to the highly painful. Challenging project “deliveries” can be the result of poor planning and execution, but they might also be through no fault of the project team’s, but rather a result of external or environmental factors. Closeout can also be a time of intense conflict between the project team and key stakeholders (e.g. mother-in-laws, new fathers)!
Throughout the project/pregnancy, the need for effective, timely communication is critical.
Having a baby is the first step in a long rewarding journey for new parents just as successfully managing a project should be the start of achieving expected business outcomes.
(Note: this bouncing baby blog post was originally brought into this world in September 2012 on my personal blog, kbondale.wordpress.com)
A team is unlikely to meet its delivery commitments if its members are constantly relying on the project manager, their people managers or stakeholders to progress. If the project manager calls all the shots, it’s rare that team members will begin to rely on one another and unhealthy tension is likely to emerge as each team member vies for more attention from the dominant stakeholder. While it is more common to see it referenced in the context of agile projects, the idea of a self-managing team can apply equally well to traditionally run projects.
A lot has been written about the ways in which a leader can facilitate team development, but what are some of the key signs of self-managing, high performance teams?
Accountability from within: On self-managing teams, rarely does someone from the outside have to remind a team member of their commitments. Each team member has a high level of self-discipline but is also keen on ensuring the team’s credibility remains untarnished and they will go out of their way to help or coach fellow team members who are at risk of missing the mark. They will also not hesitate to ostracize or eject a team member who repeatedly demonstrates an inability to help the team progress.
Embedded continuous improvement: The team owns its work practices and continually assesses the effectiveness and efficiency of these practices. When defects occur, the team doesn’t start the “Blame Game” but seeks to identify and implement methods of prevention.
Unconscious yet effective delegation: When a new work item emerges, who will need to work on it rarely needs to be negotiated. Each team member knows and respects the unique abilities of his or her peers and the assignment of activities begins to resemble the ball passing abilities of a high performing, highly cohesive sports team.
Organic onboarding: When a new team member joins, the team as a whole takes the effort to learn about the new team member’s competencies and experience. In turn, they will also ensure that the newcomer learns the same about the rest of the team and is taught the written and unwritten rules of behavior which the team follows. With such teams, it is also rare that a decision is made to bring on a new team member without the team’s involvement in the recruiting process.
A culture of recognition: Self-managing teams rarely crave or actively seek individual recognition from without. They share equally in the success of the team as a whole, but recognize each other on a daily basis in small ways with simple rituals such as picking up a coffee for a team member who is too busy to go and get one. They also begin to develop a higher level of emotional intelligence with each other which helps them understand when a team member is down and in need of some encouragement.
Sounds like nirvana, doesn’t it?
Two reasons we so rarely see teams demonstrate all of these signs is the authoritative approach used by many project managers, sponsor or people managers and the inability or reluctance for many organizations to form teams which persist from project-to-project.
As with most organizational performance challenges, we have seen the enemy, and he is us.
(This article was originally published by me in December 2014 on my personal blog, kbondale.wordpress.com)
In one of my previous articles I'd written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization's model for project funding will have significant influence over successful agile delivery.
Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.
The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.
So what challenges arise from a project-centric funding model?
It can result in higher risk, premature financial commitments.
Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint's worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.
Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?
It can also encourage sloppy product management.
When product owners receive funding for a single project and don't have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product's capabilities.
Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.