Agile project management with scrum – Optimizing value

In the recent past, there are more companies embracing agility and using scrum in project management to improve stakeholders experience and fix time and cost in an effort to control requirements. This is swimming against the currents of traditional project management which was working towards fixing requirements in an effort to control time and cost. Working in teams and adapting the scrum way of working increases the capacity of the team, but also improves stakeholder confidence. The project manager is able to collaborate better with the sponsor on the project’s progress. Seen in this image are the different roles and responsibilities in scrum ownership

Normally the process is not comlicated and involves the execution partof project portfolio management. Once the projects vision is defined and the business value that it is expected to meet, the product features are then ranked based on their order of importance. The product owner, will normally maintain these features in the backlog. Normally at this time, the features have not been estimated, but are broken down into small functional units. A joint of the team is then collaborated to select the items from the product backlog which they deem possible to complete in a single sprint. Theses items form the sprint backlog and are part of the sprint-planning meeting. There is no particular fixed period for a sprint but is always advocated that it is better for it to be between 1-4 weeks. Personally, I have experienced that alternating 1 and 3 weeks or 2 and 4 weeks always gives a better rhythm to the team and creates harmony. Towards the last stages of the project, there is always fatigue and members are eager to be done. That is why this swapping helps to keep the team focused.

Getting committed to the sprint backlog, means that the project will now be under lock and the team commences in their work. Any changes that affect scope, schedule, or budget have to be issued through the change request and are only allowed into the product backlog not sprint backlog. In the docurse of sprint development, the team remains updated on each others’ progress, commonly known as daily scrum. When the sprint nears completion, the team gets to present the job done to the stakeholders. It is also the opportunity where the team gets informed about the next sprint and also hold a retrospective meeting to understand how they can improve. It defines an important part of scrum meeting, since these are building phases of the phase gates and will ultimately define the success of the deliverables. It focuses on the three pillars of Scrum: transparency, inspection, and adaptation.

As a better practice, organizations should through their governance structures encourage the use of scrum and sprints to execute operational value-add projects for their portfolios, perform due diligence, and institutionalize their value-add capabilities. This helps to create project value visibility and the portfolio manager during their periodical meetings with the project managers, is able to see which projects should be financed further and which ones should be stopped. As the high value projects take the center stage, it reduces the amount of work to be done and helps the team to concetrate better instead of running multiple simultaneous projects. Consequently, this gives birth to increased productivity and better adaptation to project management optimization.

To communicate progress and provide frequent status updates, agile uses sprint burndowns and release burndowns, task boards, backlogs, sprint plans, release plans and other metric charts. As PMBOK states, the only artifacts required by scrum are the product backlog, sprint backlog, release burndown, and sprint burndown. All other forms of documentation are left up to the team to decide. Agile’s rule of thumb is that if the artifact adds value and the customer is willing to pay for it, then the artifact should be created. Artifacts created because “it’s on the checklist” or “we’ve always done this” are items that should be considered for elimination. Documents required for governance issues (audits, accounting, etc.) must still be created, but often can be streamlined.

So, what approaches does your team use in executing projects? Kindly share in the comments.

Enhancing project governance in a project team

I had a colleague once who quit his former job because of “unrealistic decisions by the project manager”, so he claimed. I tried to prod him further on what he thought the project manager did wrong and what his proposal to the problems would have been. Without hesitation, he quickly replied, “stand up to the management and advice them on the best way forward.” Later on, I came to understand what he meant as I found myself in an almost similar situation. In a well-governed project team where members are informed of the boundaries as team members, there is no feeling of capability restriction by the project manager. Often, there are always ambitious members in a team who would like to do more than the project’s scope. The problem is that this may not augur well with the planned budget and there could also be time constraints. The question is how does the project manager alienate the project team to the defined governing boundaries while maintaining cohesiveness and team spirit? Several factors have to be illuminated in the project team as we will see below:

Benefit owner/sponsor presence

governance-project-management

An organization with a good governance model, runs their projects at the behest of the sponsor and benefit owner. These two entities should be identified at the initial stages of the project since they are the ones responsible for facilitating the business case. Once the business case is approved and the charter documents signed, it is the project sponsor who becomes responsible for finding the resources and setting the project team’s vision. They are also recognized as the main decision makers responsible for benefit measurement, and should therefore work hand in hand with the project manager and the rest of the team in fulfilling the project’s output ensuring that they are well aligned with the business strategy and the planned benefits.

Detailed Project management plan

This is necessary for a project manager to have as it is what guides the team within the confines of the project initiative. It is also used by the project manager to align the project on the benefits register and maintain the BRM

project-plan

plan updated. This consequently makes it possible for the program and

portfolio manager to collaborate in the development of the business case and charter. The team members input to the project management plan remains guided by the governance model of the company

Project reporting

In the course of the project cycle, there is always alot of activities such as cordination with the other project and program managers, risks, changes,

reporting

emergent benefits or even unexpected costs. With well detailed reports (project reports, budget reports, briefings to stakeholders), it becomes easier for the project manager to keep the steering committee abreast with the development of the project. The key decision makers get enough and relevant information which makes project governance tenerable as it becomes apparent when making projects comparison.

Engaged stakeholders

During scrum meetings, it is not always possible for all the stakeholders to be present. This at times may create problems where pertinent issues may need their input. Sometimes, the need to accomodate changes may come later in the project and may not be within the budget. Engaged stakeholders

stakeholders

play an important role in the governance of the project, by addressing these issues. They create the link between the project team and the end users and help the project to be aligned with the stakeholders expectations whilst staying within the boundaries of the project management plan. Importantly, though, the issues raised may be taken together with the other relevant decision making authorities such as PMO, without necesssarily creating time constraints on delivering the outputs.

Review lessons learnt along the way…

Team collaboration should not just be about completing the project and getting a pat on the back. The project manager should ensure project review is done and the team contributes with their experiences. If for

lessons-learnt-2080

example, a software developer checked in a software release in the wrong branch or corrupted the HEAD of the version control system, then this should be taken as a lesson. There should be proper measures undertaken to avoid a recurence of the same in the future. By sharing such lessons and putting fail-proof measures in place, it improves the culture of product delivery and governance . This guides the team in the future, allowing which boundaries a procedure should be undertaken.

Benefits review

It is important for the project manager to continously perform a benefits review and project audit to ensure that it will serve the purpose it was intended for. This avoids disappointment, time wasting and unnecessary budget expenditure. The project manager is responsible for performing this in collaboration with the program and portfolio manager through the benefits register and review of the BRM plan. Auditing the project during initial or execution stage is critical and requires stakeholders input as stated earlier while considering the teams input on the project management plan.

The above named factors are what I consider critical in enhancing project governance in a team. These should be followed along the bes practices of project management as envisioned in PMI for a fruitful outcome. Is there something that you think is important that I didn’t mention, don’t hesitate to give a shout out in the comments section.

The more things change, the more they remain the same

The business world is transforming daily, incorporating new demands from stakeholders and becoming increasingly complex. The pace at which this transformation is taking place is faster than ever witnessed before. With increased network infrastructure and speed, anything and everything can actually be digitized. Companies are struggling to meet the ever growing demand of “delivery convenience” to avoid loosing the market share. One constant thing that never changes is CHANGE itself. The foundation of any successful organization has traditionally been to be ahead of change. This is important in a business environment and is not about to shift.

Digitized security at an airport facility

Apparently, we have all witnessed how in the last decade, security has been digitized to a level never seen before. In the wake of increased acts of terrorism, security has scaled to new technology heights. Project managers entrusted with securing buildings, airports, train terminals and so on consistently strive to drive these changes, aiming to yield both tangible and intangible results. Commercial buildings with good reputation and enhanced security levels have higher market price per square meter yet it will almost be impossible to find a space that is not rented out. Shoppers will feel secure parking their cars and walking in to a mall where there is better video surveillance and can easily wade of attacks before they occur. Such stakeholder demands calls for digitization of services to increase business value creation.

The decision to digitize services and products lie solely with the management, born out of a desire to improve effectiveness and effeciency, but one thing is sure; Nothing remains the same except CHANGE. What could be interesting is to know in which context should digitization be embraced and how should it be effected to meet business objectives and satisfy stakeholders’ expectations? Which risks could affect the strategic goals of an organization? As a PM, how do you increase chances of success in a digitization project?

Digitization it is. 🙂