Tasks delegation in project management

Delegating tasks in project management is a skillful art that is acquired over time. It is a tool that every ambitious project manager should have in their back pocket, if they need more work done. It is no longer news that as a project manager, one can’t perform all tasks, but can manage and coach their team to do the tasks. There will be never enough time to get the project done, but by delegating, the project manager gets to have more work done by the team and helps to keep the project within the timeline.

Being a team leader, the project manager should know how to delegate tasks, give support to team members and make the process a great experience. The project manager should not just delegate tasks and then disappear, rather they should be available to answer questions and specifics about the task delegated. They should help the team to understand why they have been delegated the task and what the results will mean. A

Courtesy of study.com

simple statement like “The results will be used by the portfolio manager to determine whether we should get more funding for project X” may cheer up the team, knowing that they are dependent on project X to create an impact on the business values. At times, though genuinely, it can be delegated by informing the team member that you simply rely on their expertise and there is no one else good at the job, that you could delegate to. It boosts morale, though it should not be said as a flattery excuse. The project manager should also avoid micromanaging the team after delegating tasks. It simply kills morale and is annoying. A one in a while follow-up is ok as it creates a rhythm for results expectations. An hourly follow-p and the next thing is a “sick” team member who can’t come to work.

As a project manager, one has to realize that their role is not about doing the same tasks they did before, rather they are supposed to provide leadership role. This means that there is expectation that the tasks one did before will most likely be done by another person in the organization. It is therfore imperative that the project manager develop a competitive team and learn how to delegate tasks to them. While the team is working on a task, the project manager should once in a while view the task from their perspective and understand that it is a learning experience for them. More responsibilities should be assigned and trust gained to help them grow. I remember when I started to explore Linux in the organization I worked for, I was the only one who had access to the servers. No one else in the company understood how Linux worked and I had the priviledge to be the pacesetter. It gave me the priviledge to come up with custom solutions and slowly learned the standard way of doing things. Today I am comfortable working in Linux, because of the trust I gained at that time. I coach new employees in Linux servers and ensure that they are allowed to mess up, though in the development platform.

A project manager while delegating work, should explain it to the team in a sufficient manner on what the task entails. Hinting does not work here. If not sure, don’t delegate the task, it leads to half done job, animosity and feelings of disappointment. The team on the other hand feels distrusted and untrusted or their competency ego may be bruised. Explanation should be done a t a higher level and if need be, then engage the key stakeholders in a meeting where the team can field questions to gain a better understanding of the task.

So, how do you delegate tasks in your team? I would love to hear.

Being a steady project manager

When working with projects, project managers often focus so much on getting the deliverables completed on time and budget and within the project scope. Without sound and proper decision-making skills, the project manager risks making hushed decisions that can be far away from delivering the strategic objectives. A team led by a skillful project manager should portray a well cultivated culture of non compromising on integrity and ethics. Some of the skills that the project manager should possess include:

Integrity: Seldomly are decisions made with certainty, because the future is always uncertain. A project manager can easily make decisions that

borders between right and wrong. It is therefore imperative that a project manager should adapt the right skills to make decisions and entrench the same in their team. When integrity is compromised to deliver values, it may work temporarily but in the long run will hurt business and reduce their effectiveness as a leader. An easily compromised project manager, risks setting the team on the wrong path and should likewise not expect his team to be integral. Maintaining integrity by setting clear operational principles for the team at the beginning of the project and consistently acting within those principles throughout the course of the project despite the difficult experiences lays a solid foundation for the whole team.

Adaptability: PMBOK defines strong methodologies and standards that drive planning, implementation and review processes for project management. At times following these best practices and methodologies can be so exhausting, that it ends up hampering flexibility. As a project manager, knowing the methodologies is a great asset that should be enhanced and combined with proper knowledge on decision making. This should be coupled with flexibility on the course of the project to ensure that the deliverable is on course to deliver values and help achieve benefits. This dynamism enfolds along the way during project execution both when there are limited resources after allocation and when a major stakeholder reviews their demands. In such scenarios a solid knowledge on decision making becomes an asset on whether a project should be terminated or not based on how well they suit the organizational strategic goals.

Judgment: In project management, project managers are conveyors of information between their teams and the other stakeholders. This communication are useful and should be used by the project manager confidently to make reasonable judgements. The decisions made affect all the other stakeholders and the organization’s overall performance. Some of the important aspects to consider include: patience and trust. It is only seldom that big decisions have to be made, and they need time and proper inception before making any action. The possibility to correct decisions may be costly and at times the decisions may be irreversible. It is therefore important that decisions are allowed to take time before they are made. This creates room for judgements based on facts and proper weighting of the aspects at hand. Trust is also an important factor to consider and requires time to be built within the organization. Project managers who are trusted to make the right judgements have a history of getting facts right and consolidating unbiased information from the organization. The learning curve isn’t a straight line, and there is need to support the sponsors and senior management to acquire the necessary knowledge that aids decision making. After all, making the correct judgement is backed by a solid experience.  
By applying these 3 core skills in leadership development, a project manager earns team confidence and stakeholders trust in working towards a successful conclusion.

Decision making in project management

Making sound and well informed decisions is critical in project management. It is one of the tools a project manager should have in their back pocket, ready for use at anytime.

Organizations are now getting more corncerned with project managers who are able to make decisions in complex problems. The challenge faced

by most organizations is that it is not easy to define a good decision as the right decision. It is not possible to have a proper vision on whether the decision made will turn out to be the most feasible or not, but a project manager should be able to know whether it is a good decision or not. It is therefore of utmost importance that project governance structures integrate conditions for good decision-making as part of the company culture. These conditions are but not limited to;

Evidence

For project managers to be good decision-makers, they should have access to the correct data and contact to the right people in the organization. Having access especially to unadultereted data is key to knowing how any situation started and give them a better chance to assess the current situation and know the developments that have taken place since then. Any processing of the data risks selecting which data to emphasis, and introducing a bias in the way it is presented. If every decision-maker gets the same processed data, they are all subject to the same bias which may not necessarily be what is intended. For instance, a new member in the team who is told that it is routine for us to work this way, may be limited to the team’s work process. A good project maanger will let the new team member unleash their potential in a guided manner to know how this can be applied in the team’s working formula.

Authority

The project manager should be empowered to have the full authority needed, to make and commit to the decisions that they make. This is majorly about legitimacy and the established status, but also partially about the intellectual authority. Do they have the experience and expertise to make a sound decision? Project managers should also learn how to engage the other stakeholders and delegate powers to team members as long as they retain the ultimate authority.

Process

The process of decision-making can embed faulty analysis and bias; or it can counter them. So training is vital, to help decision-makers understand how to structure their process. This includes creating proper objectivity, and the need to balance data gathering, analysis, and exploration, against the need for timely decisions.

Good decision making skills are not easily achieved just by experience. Projects are in nature not always deterministic and they will be different challenges experienced in project management. PMI advoacates the usage of Code of Ethics and Professional Conduct for project managers to help them instill cofidence in making wise decisions. The project managers should also often seek the advice of operational managers who are in charge of running businesses in their organization as advided by PMBOK. By wielding the power to make decisions the project management should exercise authority within the governance framework of the company but still be guided the profession’s ethics especially when they are asked to compromise their integrity

Project Kick-Off meeting – In the footsteps of the project manager {2}

Previously I have covered 2 posts about the kick off meeting and why they are important. Yesterday I mentioned about how as a project manager you can prepare for this meeting and help the team to be ready. Today I will conclude this discussion on where I left it yesterday.

Teamwork: Often, it is the same team that gets to work together in the same projects. At times though, there is cross-organizational projects involving external sponsors and customers. It is important that all the involved stakeholders are part of the kick-off meeting in such a set-up. It helps set the pace on how the team will collaborate, communicate, meeting frequencies and helps small details that would otherwise have been ignored to be properly addressed. The team members have a chance to be familiar with each other, which reduces anxiety. As a project manager, the important part that should be taken care of is to make sure that the expectations are well and articulately spelt out to the team and let them develop a working relationship on how to deliver results. The project should however still be monitored and managed but not micro-managed.

What next?

Yeah, that is always the big question. The team members have been informed of the new project and there is excitement in the room. There is always a temptation to jump straight into the work and begin working on the juicy part. As a developer, I have experienced numerous cases where

team members start to code functionalities of a program, they barely have understood how they work, which always ends up in defeat. As a project manager, the next steps involve keeping team members clear of their roles, expectations and milestones along the way. It is the moment that the kick-off meeting should be rolled backwards from anticipation towards results. It is also necessary that the project manager gets to know the client, their expectations and requirements before diving into any project. Traditionally, companies used to have clients come over for a meeting, which would be marked with very formal tones. Companies are now changing the trend and at times it may start with a company visit to familiarize yourself with the client and drop the “business” acumen. It works most of the time as it helps the client to know that these are people who are going to deliver quality to his work. The project managers should use this opportunity to get to know their clients and develop a working relationship and level of trust.

Before concluding the meeting, it is a good idea to have a recap of the meeting to give the client a review of the people who are going to work on their project. It is important that the team understands the roles played by other team members. A review of the SoW should also be performed to know what the team is doing, when to do it, how to do it and what they should expect to produce. Any other important issues that may be deemed necessary should also be put on the table towards the end of the meeting, as it is not always feasible to have all the team members and stakeholders in a single meeting.

It can not be stated enough how the kick-off meeting is important in any meeting, but any project manager worth their salt, will ensure that it is done.

Project Kick-Off meeting – In the footsteps of the project manager

Last week I wrote a post on how to set the right pace for project kick off, ensuring that the whole team is at par. As a project manager, holding this meeting with an informed team and a proper project management plan is key to an engaged meeting with the client and the stakeholders. A team that is well informed on the requirements of the project and what is expected out of it, works even better when they have an encounter with the client. This helps them to ask questions and raise concerns, something that may have been overlooked in the initial phases. Moreover, the team’s spirit is boosted, knowing that they have to create a working formula that makes the client feel confident. As PMI states, a meeting with the client is crucial in helping the team to make vital project decisions in good time, so that valuable hours, money and face-to-face client time are not spent on team debates, which the client may construct to mean internal-strife. In my earlier years of working as a developer, this was something that frustrated me everytime i was to start on a new task or project. i just had the work lumped on my board and a deadline issued. As I worked on the project, I spent countless hours trying to understand what the project was about, something that even the project manager had a vague knowledge on. From the project manager’s viewpoint, it was the business processes that mattered. From my view point, it was how to

connect the technical part to the business value. Later on, I started demanding to be part of kick-off meetings, something that made a huge difference in my approach to projects. But again, this is more of a company culture and how they prefer to approach projects. In large companies, it is usually the norm to have project kick-off meetings where players from different teams are briefed about the project and the clients get to know who will be responsible for developing the solutions. In smaller companies, kick-offs are very informal and there are usually no documentations involved. They prefer casual face to face talk over a cup of coffee and a whiteboard.

Preparation: As a project manager, the least one can do is to make sure that they are well prepared for the kick-off meeting. Documents regarding the project should be shared well in advance so that the team gets to know what the project is about. This helps the team to quickly get acquainted with the task ahead and consequently acquire any important knowledge that they may deem relevant. For instance, working on a new security feature, a team member may have concern on how this will impact a release they are set to have in production in the next year. The kick-off meeting should however not degenerate to a Q&A session, but rather a knowledge sharing platform to give a go ahead for starting. The project manager should therefore moderate the questions being asked until towards the end, to keep the meeting on track.

Who is the client? It is equally important to let the team know of how the project is important to the client. Is it a new client trying to find a new company, is it an existing client whose preferences are known to the team or is it a project that tries to check on feasibility of something else? Internal clients who have had projects with the project manager before, should also be invited to the meeting. The project manager should give an explanation of the client distinctively without bordering on the nitty-gritty details. For instance, “this project belongs to a client who recently was awarded the best htelier in the country”. This helps the team to Let them know who they are (internal/external), what we know about them, other projects they’ve worked on, and how the client likes to work

What is this project about? The project manager should address this question in the kick-off meeting, to help the team understand why they are doing the project. This should be viewed from a client’s perspective on how the project’s deliverable will help to drive their business. It is a key step that should be done with clarity to help the team understand what a success or failure looks like. Discussions with the team on how the project’s success will help to solve the client’s problems should be part of the agenda. The project manager should aim to maximize the positive customer experience by guiding the team to understand the need to deliver on the project’s success. It is the first baby steps for the team to develop a vision on why they should care about the project and also know that their work will contribute to something big. Lastly, it should also be clarified on what success means beyond timely delivery within the budget and the agreed scope. How will the project team benefit as a result of doing this project – will they develop a new capability or competency with a new technology?

Roles definition: the project kick-off is also important for the team to understand what roles they will be playing in the project. The project manager could develop a RACI chart and a RAM chart. These helps the team to understand the context of how they will fit into the big picture by clarifying their roles and responsibilities. To improve clarity, the project manager should map these roles to the statement of work (SOW) and clarify the deliverables associated with the roles, why they exist and what has to be done to make them a success. This helps to mitigate any uncertainties and improves comfortable levels of team’s understanding. This should be the area that gets the central focus of the kick-off meeting. Failure to do so, can easily derail the project.

To keep the topic juicy, I will let this first sink today and will tommorrow, give a post on the last part of this series.

Project kick-off meeting – Setting the right pace

The day has finally arrived and as a project manager, you feel confident that you have everything in place to kick-off the project and set the team running. But how do go you about this? Has the team prepared enough to start the project? Are all the processes in place? Thanks to project management skills, this can be done properly and the team can begin energized and confident about the task ahead of them. As PMBOK expresses, this meeting signals the end of planning meetings and signals a new dawn when execution gets a go-ahead. The significant role of this meeting is to introduce the team and help them understand what the project is all about and help every one reach a common level of understanding, help the team to commit to the project and finally to explain the roles and responsibilities of each stakeholder. It guides the team to have a clear vision of how success looks like, understand what os actually to be done and come to an agreement on how to work together effectively.

There is no single template on how this meeting is carried out to set the right tone for the project but surely there are guidelines of project management that enhance best practices.

In my experience, working alongside these principles of project management as suggested by PMBOK, when working with small projects of about 4~5 members, it is normally a routine that all members are involved in the planning and execution phase. Since all members are involved from the beginning, we naturally tend to have the same pace of natural flow and understanding, making it easier to begine the project shortly after initiation (Planning Process Group). These will typically be projects that run for maximum up to a month.

For projects that run between 1~3 months, it is then better that the the PM team gets involved in the planning and the team is involved in the tail end of the planning phase. This has two advantages: firstly, it helps to make quick and sound decisions provided the key stakeholders are involved, secondly, it makes it possible for the team to continue with other tasks hence not experiencing unnecessary faigue and lack of concentration. This will normally take place within processes in the executing process group.

Very large projects that are usually cross-departmental and are multiphased, have kick off meetings at every phase gate of the project. This is the opportunity for the team to be rest assured that indeed the previous phase is “certified” and they are ready to process to the next phase. But how will the project manager actually go through this phase? Don’t miss out on my next post “Project Kick-Off meeting – In the footsteps of the project manager.”

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

Copyrighted from https://hangoutagile.com/agile-scrum/

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.

Project estimation, best practices

Working on a project can be refreshing or tiring depending on whether the participants are on course to deliver the outcome on time and budget or not. This also affects the quality of the output and directly on the confidence of the team on their best efforts. Honestly, estimation of work load in the back log can be pretty difficult. From experience, I have learnt that even in a team where members have an almost equal level of knowledge, this becomes tricky.

When you have an epic comprising of several stories, and they have to be estimated, there are several factors to be considered as we will see.

Managing the estimates: When the story points have been created, planning their estimates should be done using the number of powers of 10 that it is expected to take. This is commonly referred to as order of magnitude. This is commonly so because human beings are good at figuring out whole numbers but then the memory fails beyond that. It is easier to estimate the complexity of a story point this way, as it is in the human nature to easily understand it. As a story point starts to be worked on, the team easily relates to the velocity since the estimates are manageable. One of the most common misconceptions when working with agile is that teams tend to view estimation, not in terms of complexity but in terms of the duration it takes to complete the tasks. Estimates planning can be done using several methods including, Fibonacci, T-shirts and Powers of 2. Recently there have also been more people starting to use Modified Fibonacci which is a variation of the older Fibonacci.

Estimates should be done in relative terms: Tasks in a story point should be estimated in relative terms rather than absolute terms. This has an advantage of creating mindset network but also helps to set the right pace for the team. For instance, the team could estimate that it will take twice as much effort to design a wireless network compared to setting up the firewall of a company. Typically, the best way to approach this is to start with a fairly small task that the whole team is most likely to have an agreement on its estimation and then use it as a reference estimation point. It could be the case that the team agrees that configuration of mobile devices is a 2. A task that takes five times as long will then be estimated as a 10. This does not bind the work to be done within a specific period in terms of hours or days, and also helps the team to understand the workload relations of the two tasks. Moreover, teams are able to make estimations faster since there is better abstraction from the details of the task which doesn’t require estimates add up. And as already mentioned, the team gets to see the velocity with which the sprints progress.

Estimation by story size: Working on different projects, I have learnt how difficult it can be at times to get the right size of a story let alone get its best estimate. Recently I worked on a project where I was asked to estimate the period it would take to complete the project. Apparently, it turned out that while I my estimation was very different from the project manager’s. And the source of the difference was our perspectives to the size of the stories. To avoid such recurrence, it is good practice to at times use bucket backlogging and not estimate all the story points. Quite often, when estimating with the rest of the team, we use the Fibonacci method where the sequence 1, 2, 3, 5, 8 and 13 are applied. Depending on the number of story points and the sizes, we are then able to choose for instance, 3, 8 and 13. These are referenced to as buckets. The stories are then estimated on whether they belong to the 3, 8 or 13 bucket. Over time, the team has embraced this method as it does not put so much pressure on team members to achieve perfection rather on completing the estimation task. This keeps the whole team focused and engaged on discussions.

Different team members use different approaches to estimate the workload on their backlog. As PMI states in PMBOK, estimation should take into consideration severalcriteria including duration, cost and resources. I would like to see how other teams estimate their work load

From Strategies to benefit realization. Closing the gap

In my post yesterday, I highlighted why the BRM concept is useful for any management that is serious in steering the organization towards realizing strategies. Today, I will discuss how this gap can be bridged through BRM. Having known the importance of BRM, management outght to come up with a good approach on how to implement it in their organizations. To do this, we will look at the following factors:

Portfolio management based on strategic outcomes: As explained in my post yesterday, most organizations still assess the value of their projects based on yesteryear parameters such as time, scope, and budget. Naively, they use these metrics and consider that projects that are completed punctually and within the provided budget to be great success, even though they may have no connection to the strategy of the organization. To turn around this, the organization needs to start thinking along the lines of project management and how they can measure success differently. This is a daunting task, even for BRM-mature organizations. A case in study is an organization that goes ahead to develop an app for its customers to help them boost sales and lure their customers towards more purchases. It could be the case that the IT department develops and delivers the software as agreed on schedule and within the budget. This will be touted by the organization as a great success. However, if the customers aren’t using it, then it won’t in any way have an impact on the cash flow or improve the company’s financial status. There needs to be a clear roadmap that neworks strategy and project portfolios for projects that are being undertaken. This needs organizations to develop a culture of genuinely defining, managing and tracking progress against KPIs that are explicitly tied to strategic outcomes. The mangement needs the nerve to kill projects which wont yield any strategic improvements.

Communication arena between executive and leadership team: There should be an active engagement and shared responsibility among theexecutive management who set and approve strategy, business owners who translate the strategy into projects with targeted outcomes for their area of the business, and project managers who manage the execution of projects to realize those outcomes. Getting these three stakeholder groups to be engaged is a key priority for ensuring benefits realization. In many organizations, ensuring shared responsibility across these groups to meet strategic business outcomes is a clear opportunity, that should not go unrealized. Continous dialog between these stakeholder groups is vital during project execution. Transparency on how well projects are helping to achieve strategic outcomes does help to create space for dialog and gives the executive the need in-depth information and insight they need to have broader strategic discussions early on and on a continuous basis. This creates room for making course corrections where it may be necessary.

Creating an environment for success and having the right team: To grow to a level of BRM maturity, there is need for organizations to invest in the right environment. They need to understand the needed behavior and where they may be forced to change company culture. These may include the needed to have frequent assessment and realignment of projects to meet strategic outcomes, high level of accountability for project progress, quick decision-making characterized by solid problem solving and ability to prioritize solutions, and give early warnings on issues that could be risks. The management should embrace constructive dialog with the project managers to forge a united working team and improve BRM growth. Additionally, project managers should be supported to acquire the right skill set and be acquainted with their working domain.

With the right insight, the management should provide a big-picture perspective and guide the organization to pivot both individual projects and the overall portfolio to be able to better capture the projected value. BRM helps create this visibility and insight, serving as a compass that points to “true north” regarding the company’s strategy, highlighting deviations between project objectives and outcomes and that strategy, and giving leaders the opportunity to course-correct at a point where small changes can still make a big difference. That ensures that the management can take decisive action to support those projects that most directly link to strategy, hence closing the gap.

BRM in organizations. Why bother?

Benefits realization management (BRM) is an important business concept that helps organizations to realize value and benefits in their businesses. But how exactly do they work with it? How does an organization get this important concept integrated in its company culture? One of the great challenges that most executive management face in their organizations in managing initiatives, is the application of yesteryears measurable outputs regardless of whther they are able to monitor their ability to satisfy organizational strategic goals or not. The most commonly used parameters include time, scope and budget but there are also others which use company specific parameters to do so. The outcome is a clear gap that emerges between strategy and project management. At times the management is unable to see this and even when they realize, it may be too late and may not know how to solve the issue. But can this be timely resolved and ensure that the company does not derail? Yes, as we will see shortly.

The bridge between the strategy and project management can be built with proper practices and mindset. Welcome to BRM. This is a powerful approach that can bridge this gap by aligning projects, programs, and portfolios of the company to its overarching strategy. Its the correct oath for a company that is keen on delivering measurable benefits. As stated in PMI’s website, organizations that are BRM mature are more than one and a half times able to to realize project objectives and three times likely to meet or exceed their target ROI on individual projects in comparison to their counterparts.

A while ago I was talking to my new bank contact who had recently started and was enthusiatis about her new job. She had some me an invitation to review some of the figures on my mortgage. So I walked in to the bank and we had a good lengthy conversation and seeing that it was on a Friday afternon, she had time to accomodate free talk.

So I engaged her in a “interview” to understand how they work with BRM. You don’t get lucky twice in life. She had been a consultant in a real estate company before switching jobs and was well aversed with what I was talking about. As her face lit up, she removed her glasses and reached out to her cup of coffee. Then she responded…. BRM is a continuous journey through which a company can learn by doing and improving their performance over time. The problem with most companies is that they give up too soon or don’t want to find the mantra, she continued. Accordingly, rather than attempting a quick and sudden change in how most management approach strategy and project management, they should instead focus on generating significant benefits by growing in BRM baby-steps before they can make great strides and build up experience. Then it occurred to me, that it is exactly the same thing a parent does by taking their children from being and infant to adulthood, with one focus of being self-reliant in life. Organizations should keep on ploughing their plans, revising their concepts and work forward towards delivering their strategies. BRM does this by helping to maximize initiative values by incorporating and articulating accountabilities across stakeholders to identify, execute, and sustain strategic outcomes.

Indeed, organizations that have embraced BRM do not necessarily ooze perfection. Far from it, they accept that there is always room to learn and improve. Rather than being comfortable, they are willing to jump in, live with imperfect processes, yet begin to make pragmatic steps towards being better. Since the business is always developing, they are keen to use every opportunity available to move forward. They begin closing the gap between strategy and project management and give themselves a source of competitive advantage that pays larger dividends over time. But we may wonder, how do they close this gap and still remain competitive? That is the subject I will cover tommorrow. Stay tight as I cover this in my next post tommorrow.