MISSION

Our mission is to

Bridge the gap between technical excellence and stakeholders’ business goals by providing rapid customer-centric solutions that deliver value and compelling experience to our customers

Virtual Teams, do they perform? Or….

With the advent of Covid-19, most teams in practically every industry have been hard-hit with uncertainty on how to sustain performance and ensure they remain actively engaged to the goals. Stakeholder satisfaction has gone south for most of these teams and it is increasingly becoming frustrating for leadership to regain their glorious past of co-located teams. Talking to one of my friends who is a project manager, he told me “I have simply lost it. Nothing is working anymore, and our backlog looks like a jungle.” This is not unique for only this team but is something that most teams are continuously experiencing. It is even worse for teams that previously were struggling to function when they were co-located and have now been thrown in unfamiliar territory. Within the last two years, my experience with other teams has shown that there is a myriad of challenges but there are some which are common, despite the industry the team is working in. I will highlight 3 of these issues and then in my next series, I will address my supposed approach to handling them.

Lack of unified goals

It used to be easy to define a goal around which a team could rally their focus while working on a set of issues. In Scrum, this has always been the norm before any set of issues are chosen by the team. The product owner defines the goal and a whole list of prioritized issues from which the team chooses, based on their understanding of these issues and their velocity. Arguably, most teams did not find this to be an issue and it is quite impressive that Agile defined this approach so well, addressing the traditional centralized authority. However, while working remotely, it is increasingly becoming difficult to have an understandable unified goal which teams can use to deliver the next increment. This is not because they don’t communicate, but it is because the level of team engagement has been severly compromised, that most people find it frustrating to remain actively motivated. I have seen fluffy sprint goals such as “Solving issues from Revision 3.2.4“. The problems with such goals are that they create dependencies and do not really motivate the team. Some of the goals are defined based on a single stakeholder feedback, which in actual sense creates imbalance in stakeholder satisfaction. By using feedback from a single stakeholder, the whole team gets blinded to the needs of the whole stakeholder fraternity across the spectrum. There is a genuine need that goals aren’t individual-centered, if the whole team is to gravitate their efforts around them to achieve satisfaction equilibrium.

Lack of Support from Top Management

Teams working without the support of the top management are prone to experience instability and disruptions within their iterations. This is commonly in the form of in-coming work from customers and colleagues, urgent hotfixes, or even changes of the team’s plan by the management. Such teams suffer from being unable to execute their work within locked timeframes that allow them to deliver an incremental release of the product. When management is not in tandem with the activities of the team, do not participate in reviews nor are they aware of the current status, then the two units drift apart. It is common to see efficient agile teams being managed by leaders with old-mentality of project management. This causes rifts in achieving any meaningful progress, mostly because the team feels that they are not respected by the management and their efforts are not appreciated. The bigger and “ugly” caveat is that the team finds it difficult to tie their activities to the goals and objectives defined by the management. On the lower side, it leads to a frustrated team at a crossroads on achieving their sprint goals and satisfying the demands of the management. On the upper side, it leads to an organization that cannot adapt appropriately to changes, failing in achieving to align the teams’ activities to the strategic goals and non-achievement of BRM.

Sect-like/Religious practice of Agile

While agile is flexible and can be customized to different industries, it is not uncommon to see teams embracing agile and following it rigidly. Often, when top management advocates for teams to embrace agile, there is a poor change management process to help the team transit to the new way of working. If the team does not understand why they should use agile, or the activities and ceremonies of agile are followed in a sect-like manner without any understanding, it is doomed to fail. Team members sooner or later feel the pressure to deliver incremental value during each sprint. It feels like being put on a pedestal without having any room to gasp for air. Working virtually, compounds the problem because the team members lack face to face interaction (one of the 12 agile principles). Additionally, it introduces long waiting times that delay the workflows. Teams should be allowed to embrace agile and suit it to achieve their objectives. Sure, this does not mean compromising on the activities or goals of the team, but by remembering the 4 values of agile, it is believable that agile can be embraced even by the faint-hearted. The beauty of agile is seeing the incremental value the team produces at regular intervals. Combined with the transparency of the team’s progress, it enables the team to be reflective and adaptive, ultimately becoming even more productive. The team should be able to see the outcome of their activities and relate to the goal they are achieving, and whether it is delivering value or not.

Thanks for 2021….

I would like to thank all my readers and those who have shared valuable ideas and lessons that have helped to share this blog. I would not be here today if not for you constructive criticism and feedback that ave defined the content of this platform. As we move into 2022, I am looking forward to a more engaging platform, where I will not only have readers, but that we should view each other as partners. Partnership where knowledge and learning process are amplified and we share our experiences in a more engaging manner. Wishing you all a happy and blessed 2022.

Disaster Management. How prepared is your organization?

This week brought forth a popular yet less revered subject to the limelight. Disaster management or crisis management is one of the things that most leaders know that they ought to have drills on, but is seldom taken with the seriousness it deserves. I find this to be true, whether in small, medium or large organizations. In the software world, disasters have led to multi-national companies being dragged to endless court battles, often loosing their reputation and invites competition to hawk-eyed competitors. This is not only true for blue-chip companies, but also for small start-ups that often ignore the need to be reflective and adaptive. Take the case of Barrings Bank, London, which faced one of the greatest banking disasters, when one of their employees brought it to it’s knees. Nick Leeson, a rookie who quickly escalated the career ladder in the banking sector, transacted on the Singapore International Monetary Exchange (SIME) for close to a year, unnoticed. While it may be termed as a poor oversight on the business operations of the bank, it also leads to different thinking on how many disasters can be avoided, if the leadership is proactive and there is a clear definition of responsibilities.

Back to what happened this week, our IT team lost the storage server that controls the VM’s, the domain controller, and a host of other critical servers. Initially, it was underestimated to be a minor problem that could, as usual, be resolved by restarting the storage or some other server in the server room and bingo!!! No, it was not the case in this situation. The situation quickly escalated to a series of “Yeah, we are almost back to business…” to “No, this is not true, it is not happening…” to “How come we did not see this…” and in between, there were accusations and counter-accusations. This did not help the situation either, as the environment soon became too toxic, and meanwhile, there were frustrated employees and customers who could not get their concerns addressed. The whole situation was even made worse by the fact that there was no proper communication on the whole situation and no one took charge of the chaos to restore normalcy. After realizing the magnitude of the problem and undergoing through the denial phase, they had at least undergone half a cycle of the Kubler-Róss change management model. Realizing the magnitude of the problem, the next step was to contact a consultancy company to help resolve the problem.

To say the least, it was an uncomfortable situation to be in, and I had my fair share of lessons learned on what “Chaos” can do to an organization. The following three invaluable lessons are things that I walk away with, from this situation.

Communication: It cannot be said in any better way, than simply telling the team to COMMUNICATE. This is both within the team and also outside the team. How are the stakeholders kept informed of the situation? Do we push information out or do we sit pretty and wait for stakeholders to pull the information? In what platform is the information delivered? What content is delivered to stakeholders? How do we manage panic and stress levels amongst our stakeholders? Who is in charge of the communication process? Are we delivering information frequently and in a timely fashion? All these are important factors to consider if we are to ensure that communication is well managed and monitored.

Leadership: In the midst of a disaster, it is at times difficult to remain sensible, making it natural to panic and make blunders. It is even easier to point fingers and imagine that someone else should take a fair share of the blame. Does it solve the problem? Not at all. In fact, it does the opposite. The leadership has to take responsibility and give direction on how to restore normalcy as soon as possible. Engage your team to understand what the problem is before trying to “solve any problem”. Is it Unknown-known, known-known, Known-unknown, or unknown-unknown? What is the relationship between the cause and effect of the problem at hand? Which constraints are involved in the situation at hand? As a leader, are you asking enough questions to keep the team engaged? How are you as a leader helping the team to collaborate and work towards coming out of the chaos?

Problem-Solving: How do you resolve the problem? Is the whole team working jointly on one issue at a time or are there well-defined responsibilities to widen coverage? Are the team members continuously regrouping to compare notes or are they working in silos? What valuable lessons are you learning from each other along the way and how are these leveraged to quickly come out of the woods? How are decisions being made in the midst of the disaster? This is very important as there may be no time to make a proper analysis and evaluate the consequences of the decisions made.

These three lessons are important in the midst of a disaster. But there are even other equally if not more important lessons, which should be covered after the disaster. How does your team handle disasters? As a leader, how do you handle disasters? If you never had a disaster, then it is time to take heed and be proactive, making simulations of how to handle such situations. Kindly share in the comment section, your experience in disaster recovery.

That is it!!…..

I finally got my Masters done with the best results possible. I am satisfied and can only look back with joy the process that I have undergone. It has been a pleasure to actually apply the principles of project management both traditional and waterfall in the Thesis writing. Planning was more of waterfall and execution was more of agile. There is always room for learning and it brought satisfation to see both approaches harminiously working together and delivering the results.

What next?

I have a long summer holiday ahead, which i will be spending with my family. The next step is to actually apply Scientific decision making methods in the discipling of Risk management and Decision Making to Project Management domain and see how these two work. If you are interested in joing me, don’t hesitate to give a shout out.

Thesis updates…

I have in the last couple of months been busy working on my Thesis and that is why there has been little activity on my blog. Yes, I am soon done this summer and will be writing more frequently on project management than I have done previously.

So, interestingly, the heading of today’s blog is what i am working with in my thesis. Precisely, the research question is asking “What are the challenges of agile implementation in private organizations at organization level, and how are they addressed to achieve benefit realization?” I have spent several hours reading and reviewing previous articles on this subject, to enrichen my understanding on how portfolios contribute to achieving planned benefits. In the coming weeks, I will be updating this blog, to let you have a peak in to the progress I am making and also welcome criticism and contribution. Meanwhile bear with me that the updates will not be frequent as usual, for the next 3 months.

Looking forward to hear from my readers…..

PMBOK 7th Edition

It has been a long wait for the new edition of PMBOK guide, which is set to be released very soon. According to PMI, this was delayed to January 2021 and it will only be fair to say that it should now be almost out. It is understandable that COVID-19 has disrupted businesses worldwide, but as we inspect the current status and adapt to the new status, we have to be agile. The new PMBOK 7th edition departs from the previous editions that were based on the 10 knowledge areas (Integration, Scope, Schedule, Cost, Quality, Resources, Risks, Stakeholders, Communication and Team) and 5 process groups (Initiation, Planning, Execution, Monitoring and Controlling, and Closing) to principles.

These principles are more centered around working with other stakeholders and most IMPORTANTLY sends the message of value delivery. This is a departure from the 6th edition which was mostly corncerned about processes, input, outputs, tools and how the different project phases interacted. PMI, however, has been very fast to underline that the previous project management approaches should not be rendered invalid, rather they are a building block to what the new edition advocates for. As an agile enthusiast, I am keen to see how what the new edition brings on the table. I am especially keen to see if and how they explicitly address risk management, cost management and procurement, something that the current Agile manifesto (2021 release) does not explicitly talk about. I have a feeling that the new edition also integrates Lean into the 12 principles (Stewardship, Team, Stakeholders, Value, Holistic Thinking, Leadership, Quality, Tailoring, Complexity, Risks – Opportunities and Threats, Resilience & Ability, and application of change management). Project managaement is taking a new turn and we have to be more agile than ever before. Let me know what your feelings and thoughts are about the new PMBOK 7th edition release.

Leadership – Expectancy Theory

Waterfall Model

This is one of the oldest software development models that was first brought to the limelight by Dr. Royce and has since been a point of discussion both in academia and industry. Although most development teams are embracing new technologies and development models, to accomodate change, should it be perceived that waterfall model is no longer important? Or is just the great fuzz that each company is going Agile without proper plans and preparations?

I

Personally, I find the model to be great and still practical even in today’s software development industry. It is the most underrated model even by people who have very brief and limited knowledge on how it works. It not only forms the foundation for the Agile model, but defines the kernel of software development. I must admit that it is not change-friendly especially when working with new domains or cross-functional teams. But it still contributes immensely to SW development, in terms of capturing stakeholders’ interests because alot of effort is put in capturing SW requirements in the beginning. It is a practical approach, especially when upgrading legacy systems and there is no time-pressure. Since the functionalities of the legacy system are already known, it reduces chances of changes in the latter stages of the model.

One of it’s weaknesses is that the stakeholders/PO’s only get to see the product in the implementation phase, which may be a bad idea especially if the product has not been developed as specified. I have often seen stakeholders who negotitate with development companies for a product, and then sit pretty and wait for the final product, only to be disappointed at the results. The KEY word is requirements’ specification, which again most teams have no idea what power lies behind it. As a stakeholder, if your valuable feedback is not availed during development, make sure you have a thorough requirements’ specification process. This should capture the product as you envision it, and help you relate the product to your expectations. Avoid pushing things to a later date and assuming that the PO captured your needs as required. Have a control check to ascertain that your needs are captured as expected. And as long as you are sure that this is not going to change, then waterfall model should be the best approach.

Looking at Agile, you quickly realize that it is actually a series of waterfall model whereby each phase is implemented in a Sprint. During this time, the PO locks the sprint and prevents any changes infitrating the sprint. This is not different from waterfall model, only that the sprint could be a shorter period. However, the idea is the same – mid-stream sprint changes are costly. Otherwise, it is till a very practical model in the industry even today and likewise it is used in university projects.

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.