Digitization and the Human Resource

Ishmael 2
                                   Ishmael Thaga, Country Manager, InnoLead Consulting Zambia

The growing economies of the world offer an ever-expanding choice of great deals. These shifting growth patterns and digitisation are reshaping the way of doing work across all industries. The turbulence that this brings to the job of HR is much more exciting than ever before. If an HR strategy fails to embed digitisation in today’s workplace, then the company is on its way towards its demise.

It is unfortunate that every time one mentions going digital, the immediate thought that locks a lot of heads is “job loss loading…” The reality is actually “better and exciting jobs loading…” in fact, this technological change is bringing opportunities to create more rewarding jobs and better career pathways and HR is going to play a very big role in seeing this through.

Every boardroom around the world has been on a ubiquitous move to go digital and it is the people function represented by HR partners’ responsibility to realign or redesign their human capital strategies to capitalise on the modern way of work and making sure that the people appreciate the importance of digital technologies as an enhancer of human capital outputs.

Billions of dollars have been invested in digitisation projects but have failed as a result of resistance by the human capital who were under fear of job loss. It must be made clear that, without the human input, the digitisation strategies will never be successful. This, therefore, means humans should be adequately prepared to drive this move with great comfort of knowing that they are the fundamental determining factors on whether this will succeed or not.

HR can, therefore, make sure that they are at the forefront of running this wave of change within the organisation by adopting the following;

  1. Develop HR strategies that align with the overall corporate strategy to go digital

As executives determine or scope out the digital direction of the organisation, HR has to then define how they are going to drive the digital objective through people. It is important to define specifically what the digital objective means to the overall HR function and how the plan will impact the bottom line of the organisation in the long term. The deliberate long-term plans for the HR function have to align with what the organisation endeavours to achieve and should be SMART in nature.

  1. Attract market-relevant talent to drive the organization’s digitised future

It is without a doubt that organisations will need to be deliberate with their recruitment of new talent. The Digitisation strategies put in place will require a totally new skill set which may not be available within the current pool of talent. As the way of work evolves, HR will need to recruit talent which will also add flavour to the existing regime by being the change agents towards the digitisation objective. Some of the skills which are not readily available in a lot of organisations but are key in driving the digitisation agenda are Big Data Analytics, Project Management, Programming, Understanding of Scrum and other agile methods.

  1.  Upgrading the current employees to match the new demand

The lifelong learning culture will need to be embedded in the existing staff. “Learn, unlearn, learn” should be the new order of things within the organisations. Skills upgrading to match the skills demand for the digitised organisation will have to be implemented by the HR function in order to keep up and reduce redundancy. It is clear that with the digitisation objective set by executives, a heavy training budget needs to be put in place to support the endeavours. The Internet has made life easy for a lot of organizations as free online courses and some at a minimal fee are widely available. However, specialized courses will have to be acquired at a good fee that’s worth the return.

  1. Providing platforms that encourage innovative thinking such as agile teams and cross-functional teams

Collaborations geared towards breaking silos will have to be structured in the new way of work in order to diffuse the new digitisation culture. This will also help with skills transfer amongst cross-functional teams. It has been proven that cross-functional teams are one of the catalysts to innovation thinking within organisations.  This, therefore, requires HR to push for the agenda in all possible areas within the organisation. Imagine what a seamless mobile platform that breaks the topographical barrier can do for expanding enterprises, this can open doors to the global workspace and talent which may not be readily available within the base of operation. Agile delivery also goes a long way in driving digital agendas. For those organisations that are already in the forefront with the adoption of these new ways of work, a significant return has already been pronounced as a result.

  1. Empower employees to use digital platforms to improve customer experience and make sure the impact is measured and rewarded appropriately as a motivator for employees to do it more

Everybody wants to know what is in it for them, that goes from the investors through to the employees themselves. While the digitisation agenda is meant to enhance productivity, which has a trickle-down effect on the bottom line, the people should also feel the need to be part of the processes by being rewarded appropriately. HR needs to make sure that there are enhanced rewarding systems in place as motivators for the employees to jump onto the digitisation bandwagon quicker than they normally would. This digitisation wave needs to give employees an overwhelming experience of excitement to want to pursue it more. Once that is achieved, there should be a notable positive shift in customer experience as more and more customers are resorting to digital services to break the geographical placement barrier.

Given the discussion above, should HR still be on the planning phase for the coming digital revolution? I think it’s time for execution as we are already in the middle of what used to be termed as the future world of work. Those in the forefront have already recognised digitisation as an opportunity to drive competitiveness and therefore HR should also be ahead as a critical stakeholder to embrace this transformation.

Ishmael Thaga is the Country Manager at InnoLead Consulting Zambia offering Management Consultancy and Corporate Training Solutions. He can be contacted on +260 211 251 034 

The Explosion of Agile Certifications

DSC_1627
Monthusi Ramontshonyana, PM Trainer, InnoLead Consulting

Just as we can’t assert that one medicine is best for everyone, because what is required will depend on the patient’s age, medical history and ailment, we can’t state that a particular agile methodology is suitable for all projects. Every project is unique. Some projects are relatively straightforward and predictable. Others are highly complex and risky. Each requires a different approach when it comes to how the project should be managed and delivered.

This article focuses on why the explosion and proliferation of agile project management frameworks is a bad thing. The discussion points addressed by the article will be as follows: Decision paralysis; Decrease of satisfaction; The problem experienced by hiring managers and The creation of toxic project environments

Decision Paralysis

The explosion of choice produces ‘decision paralysis’, rather than liberation. We have all seen it before, ‘decision paralysis’ – the complete lack of ability to decide. Decision paralysis can happen to anyone. With so many agile project management methodologies to choose from, people find it very difficult to choose at all. In his book titled “the paradox of choice’ Barry Schwartz an American Psychologist states that a colleague of his got access to investment records from Vanguard, the gigantic mutual fund company of about a million employees and about 2,000 different workplaces. And what she found is that for every 10 mutual funds the employer offered, the rate of participation went down by two per cent. You offer 50 funds — 10 per cent fewer employees participate than if you only offer five. Why? Because with 50 funds to choose from, it’s so damn hard to decide which fund to choose, that you’ll just put it off until tomorrow. And then tomorrow, and tomorrow, and tomorrow, and of course tomorrow never comes. In another research, when “Head & Shoulders” reduced the number of shampoo choices from 26 to 10 they had an increase of 10% in total sales. He concluded by saying ‘People usually think that giving more options is a better marketing strategy. It actually isn’t. Too many choices create paralysis. People look for simple choices.’

In a nutshell, the researches above depict the real-life crisis faced by many, who are deciding on which agile certification to pursue, as the market is rapidly changing by leaps and bounds. The explosion of agile certification is making each less and less valuable since there are too many to choose from.

Decrease in Satisfaction

Even if we overcome the paralysis and make the choice, we end up less satisfied than if we had fewer options to choose from because if you have a lot of choices and you select one, it is easy to imagine that some other unchosen option would have been the better choice. This subtracts from your satisfaction. The more options you have, the easier it is to imagine that you made the wrong choice.

The problem experienced by hiring managers

The explosion of agile project management methodologies has brought another problem to hiring managers. How can they compare or rank one over another when screening candidates for employment. What criterion will they use to say one qualification is superior to another? At the current moment there is no tool that can be used to gauge and standardise agile project management methodologies ratings like, on Amazon where products are rated by customer review star ratings, the number of customer reviews a product has received which assists customers in their decision making. This leaves hiring managers to be seduced by exotic names given to these agile certifications like ‘scrum-master’; ‘professional scrum master’ etc which could be construed to mean that the candidate has ‘mastered’ the understanding and application of a particular methodology over time and are experienced enough to be deemed masters in this field. As opposed to acquiring the certificate having watched a few online videos and writing a simple exam to be bestowed with the title ‘master’.

The creation of toxic project environments

The proliferation of agile project management methodologies has created a culture where people target to do as many certifications as possible leading to certificated project team members, which does not necessarily talk to their competency and experience. This has also widened the ‘knowing-doing gap’ where project team members appear to know a lot but they do not implement what they know. This sometimes leads to a toxic project environment where there are a lot of egos in the team and a lot of negative competition among team members, team members trying to prove that their certifications are better than their colleagues’ certifications that can dampen the team’s morale which may result in sabotage, scope creeps, decreasing productivity, time and cost overruns. This phenomenon has also somehow replaced the concept of BOTHO; people skills and being truly human in the project team environment with exclusion, disrespecting morale and using bullying tactics against other team members.

Conclusion

There is no doubt that we are in a VUCA environment, VUCA is used to describe the nature of the world in which we operate: the accelerating rate of change (Volatility), the lack of predictability (Uncertainty), the interconnectedness, of cause-and-effect forces (Complexity) and the strong potential for misreads (Ambiguity). This means no one Agile Framework is the silver bullet (no one framework is suitable for all projects), the Agile approach adopted has to be suitable for the project environment and wherever possible the Agile practitioner shall improve on or tailor any given framework to the degree that will benefit the project.

Although this diversity along with frequent new offerings—muddies the waters of comparison, it would be negligent to simply ignore new offerings since they may have been created to fill real gaps/needs in the agile project management environment.

 

Monthusi Ramontshonyana is a Project Management Trainer at InnoLead Consulting’s i-Academy and can be reached on +2673909102 or academy@innolead.co.bw

Agile: An Evolution

DSC_1627
Monthusi Ramontshonyana, PM Trainer, InnoLead Consulting

In the previous publication titled ‘Agile: An Introduction’, the focus was on introducing and defining Agile. The focus of this piece is detailing the journey of Agile from the beginning to date.

The concept of Agility doesn’t begin with the Agile Manifesto —its roots go back much earlier. Agility can be traced back to the very beginning of human existence. One of the earlier known records of Agility is credited to Sun Tzu (544 BC – 496 BC) who was a Chinese general, military strategist, writer and philosopher who lived in the Eastern Zhou period of ancient China. Sun Tzu is traditionally credited as the author of The Art of War. In a later section of this book, Sun Tzu talks about the need to be fluid and adaptable.

When faced with the challenge of adapting to a changing world, Field Marshal Helmuth Karl Bernhard Graf von Moltke (26 October 1800 – 24 April 1891) wrote in his essay titled ‘Ueber Strategie’ translated ‘On Strategy’, “ The material and moral consequences of every major battle are so far-reaching that they usually bring about a completely altered situation, a new basis for the adoption of new measures. One cannot be at all sure that any operational plan will survive the first encounter with the main body of the enemy. Only a layman could suppose that the development of a campaign represents the strict application of a prior concept that has been worked out in every detail and followed through to the end” which is popularly shortened and quoted as ‘no plan survives first contact with the enemy’

The 19th century was characterised by technological innovations like new machine guns, combined with growing army sizes, which were transforming war. These evolutions dramatically increased the complexity of battles, making them almost impossible to predict a battle’s outcome and therefore plan accordingly. On this basis, Moltke the elder came to the conclusion that sharing intentions as opposed to detailed orders would empower his subordinates to take initiatives in the battlefield and better adapt to unpredictable events. Deterministic plans were no longer relevant, and adaptive strategies should be applied instead. Since then, this concept has been applied to broader contexts including project management and business strategy.

In the early 1990s, as PC computing began to proliferate in the enterprise, software development faced a crisis. Industry experts estimated that the time between a validated business need and an actual application in production was about three years. The problem was, businesses moved faster than that. Rapid Application Development (RAD) was invented around 1991, possibly the first approach in which time boxing and “iterations” were introduced. In 1993, Jeff Sutherland invented Scrum as a process at Easel Corporation;1994 saw the first release of Dynamic Software Development Method popularly known as DSDM; in March of 1996, the first Extreme Programming project was started. The late ’90s saw the emergence of many other agile software development methods including Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.

Agile software development as we know it today was born in 2001, when 17 software thought leaders met at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, to try and find common ground. Representatives came from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven heavyweight software development processes. The outcomes of the meeting articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation.

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The proliferation of Agile Project Management methodologies did not stop with the signing of the Agile Manifesto, they continue to emerge to this date with the release of methodologies such as Lean Start Up, AgileSHIFT, Scaled Agile Framework (SAFe) Agnostic Agile etc. The PM certification proliferation is increasing exponentially. This is obviously not good and it’s not helped by the complexity of agile approaches. The next instalment in the Agile series will discuss this in more detail.

Monthusi Ramontshonyana is a Project Management Trainer at InnoLead Consulting’s i-Academy and can be reached on +2673909102 or academy@innolead.co.bw

Agile: An Introduction

DSC_1627
Monthusi Ramontshoyana, PM Trainer, InnoLead Consulting

Agile is an umbrella term for a collection of frameworks and techniques that enable teams and individuals to work in a way that is typified by collaboration, prioritization, iterative and incremental delivery. There are several frameworks that are classified as Agile, these are SCRUM, DSDM, XP, SAFe, AgileSHIFT etc. At the core of Agile is the requirement to exhibit central values and behaviours of trust, flexibility, empowerment and collaboration. Agile got its roots in the software development space, specifically via the introduction of the Manifesto for Software Development in 2001 put together by a cadre of founders.

In some projects, the requirements or expectations identified in the beginning are not reliable. If we create the products based on them, the result won’t satisfy the customer. In other projects, the lag between identifying the need and delivery of a product to meet that need is far greater such that when the product is delivered the need has changed and the product is no longer the right one. In order to bridge this gap, we use adaptive methods where we only plan for a short period in the future (using timeboxes and sprints), create a working product and use the product to understand the needs and use the feedback to plan further and add more functionalities to the product.

Multiple versions of working products are created throughout the project in adaptive systems. This is called incremental delivery. It offers customers the opportunity to use the product in its current state and provide feedback throughout the delivery period. To deliver multiple versions of the working product, development processes such as Design, Build, and Test are repeated. This is called iterative delivery, which allows the team an opportunity to meet and listen to stakeholders, including customers, on a regular basis. This feedback will be used in successive iterations ensuring continual improvement and refinement of the products being created.

Agile Project Management approaches are suitable for projects where specifications, requirements and project products or outputs cannot be clearly defined before the project commences or when the customer keeps on changing his/her mind. If you try to use predictive methods with upfront scope baseline, schedule baseline etc. the project team will be bombarded with change requests which will result in scope creep, decreasing productivity, time and cost overruns.

Not every product has the capability to be developed iteratively and incrementally. The best case for Agile is software development. Agile has also been used extensively in research projects, development of products and enhancements, sustenance and renewal of products and managing the operation of organisations.

There are some misconceptions associated with Agile which suggest Agile as a panacea in project management. Agile is a means to an end, not the end itself; the whole point of adopting Agile practices is to improve project delivery. Agile cannot solve the impossible, it can help reduce wasted time: it focuses on the right things and if it’s going to fail it will fail fast. It shortens the lines of communication and encourages collaboration. Another misconception is that Agile is synonymous with Scrum. Agile is not Scrum but Scrum is Agile, just as all Toyotas are vehicles but not all vehicles are Toyotas.

Monthusi Ramontshonyana is a Project Management Trainer at InnoLead Consulting’s i-Academy and can be reached on +2673909102 or academy@innolead.co.bw

Project Controls Expo 2018

The 2018 Project Controls EXPO came and went, and Innolead was there. The project controls Expo was organized by ProjectControlsonline.com (PCO). PCO is the largest Project Controls central repository and knowledge base with a presence in all 7 continents and over 150 countries. The 2018 Expo as held in London and hosted at the Emirates Arsenal Stadium over a two day period.

This was arguably the largest international event dedicated to the advancement of project controls. The event objective was to provide a platform for practitioners, employers, customers and suppliers to come together, share knowledge, experience, best practices, career development and software tools under one roof.

This by far was the place to be for those working within the spectrum of Project Controls not just from an educational perspective but also in terms of building a network and exploring global project management and controls solutions. This industry convergence also provided a variety of training, technical and managerial presentations from some of the industry’s best experts.

The EXPO kicked off with an awards night that celebrated the best projects and controls professionals in the field of project controls. The four awards celebrated on the night were the:

  • UK Project Management/Project Controls Apprentice of the Year 2018,
    • The Project Controls Expo awards judges were looking for the passion, determination and contribution of the apprentice as they have sought to deliver tremendous benefit in their roles to customers, project teams and wider stakeholders alike.
    • In this category, the judging criteria placed priority on the positive contribution the apprentice had made to the business through outputs and outcomes of their respective project (encompassing projects, programmes or portfolios) and recognizing their essential use of the wider project toolkit to assist the delivery of success.
  • Global Award for the Project Controls in a Megaproject 2018
    • The Project Controls Expo awards judges were looking for the stories behind these mega projects and the people that have delivered the greatest benefit to their clients, project teams and wider stakeholders.
    • In this category, the judging criteria placed greater emphasis on the outputs and outcomes of the project (encompassing projects, programmes or portfolios), whilst recognizing the essential role that the project controls toolkit and techniques have in delivering success.
  • Global Award for Project Controls Innovation 2018
    • The Project Controls Expo awards judges were looking to recognize the use of innovation within Project Controls for projects (encompassing projects, programmes or portfolios) and see how its wider use within organizations and society can contribute to successful change.
    • Innovation could include a method employed, the overall novelty of the project or the transformative outcome.
  • UK Project Controls Professional of the Year 2018
    • The Project Controls Expo awards judges were looking here for the passion, determination and contribution behind the person who has delivered tremendous benefit in their roles to customers, project teams and wider stakeholders alike.
    • In this category, the judging criteria placed priority on the all-around positive contribution the Project Controls professional has made to the business through outputs and outcomes of their respective project (encompassing projects, programmes or portfolios) whilst recognizing the essential role that the management and use of the wider project controls toolkit has in delivering success.

The awards ceremony was followed by a pre-event networking gala. The gala dinner was attended by over 300 attendees and it offered an opportunity for delegates and attendees to mingle and initiate the first contact.

The main event attracted over 900 attendees and was characterized by a series of training, presentations, and panel discussions on industry issues, challenges, developments and solutions. In addition, the event had the following key features;

Partner Showcase & Job Fair – Up to 42 Partners were showcasing a range of cutting-edge products, technologies and services for Project Controls. This provided for an opportunity to see, touch, feel and experience demos of the latest industry solutions.

Masterclass Zone This offered a great platform to study and discuss the theory and practice of Project Controls. Leading Project Controls professionals, from around the world, with extensive experience, provided educational presentations to build on one’s knowledge.

Case Studies Zone This case study zone enabled one to venture into discussions around the application of Project Controls in addressing the problems with top industry speakers with extensive global experience. A great opportunity to learn from and share knowledge from real life project events.

Technology Zone The technology zone hosted in-depth sessions where our technology pioneers demonstrated the functionality and capabilities of their innovative products.

Megaprojects Zone This covered presentations on Megaprojects are with budgets over >£1B. These projects are large investment commitment, vast complexity and have the potential to make a long-lasting impact on the economy, environment and society. This zone took one through a discovery process on how to ensure governance over these initiatives and protect the investments.

Social Project Zone – This area also hosted in-depth discussions on applying industry methodologies these “social engineering” projects will provide better value for taxpayers and deliver more successful outcomes.

SME Panel – This offered one-on-one discussions with Subject Matter Experts (SME) in Program Management, Earned Value, Cost Engineering, Risk and Forensics.

Innolead was there as Sponsor for the event with the intent to harness global knowledge and trends in the project management and controls arena. Our attendance at this event and others of similar intent is first and foremost for the benefit of both our local and continental clients.

We attended for and on behalf of all our clients and those yet to be converted. When we discover, our clients discover, when we learn our clients learn, when we grow our clients grow.

Innolead was the single continental representation and sponsor of the event out of 58 registered sponsors of the event. We continue to sponsor and attend these events because we take the project management and controls practice seriously, we take ourselves as a local and regional project management services provider seriously and more than anything we take our clientele and the service value they deserve seriously.

Our participation in the 2018 Project Controls EXPO is a further demonstration of our continued commitment to intellectual growth and drive to measure ourselves against practical global industry standards and practices.

The curse of WhatsApp group chat on project teams

Kabelo
Kabelo Bitsang, Consultant, InnoLead Consulting

Project teams have correctly embraced mobile technologies but this can have downsides and actually harm the project. WhatsApp is the most popular messaging service in Botswana and its group chat feature is being used by project teams to stay in touch and coordinate activities.  While using this service seems like a simple way to improve team communication, it actually does more harm than good. WhatsApp group chat has the following (sometimes hidden) downsides.

The all-day meeting

Good project meetings have a clear start, end and narrow focus.  Meetings are a necessary part of project life but in a WhatsApp Group chat it feel like you are in a meeting that never ends. An issue can be discussed all day without any resolution because there is no time limit to the discussion. Since the team cannot all look at the same screen to discuss a deliverable it can be unclear what is even being discussed. Unlike a structured meeting, on WhatsApp, anyone can speak at any time and there is no thread to the conversation. The unstructured nature of the conversation will make it difficult to close issues or even set deadlines for closure. You can think an issue is resolved only for someone to open it up again 5 hours later. Project teams have a tendency to mix in important announcements with casual chat leading to a situation where you have to read everything for fear of missing out. Some teams can suffer from too many face to face meetings which use up valuable time but WhatsApp makes the situation worse by creating a meeting that never ends.

Governance is thrown out the window

If a project team uses a group chat application this can seriously weaken the governance and controls. With WhatsApp, there is no separation between project decisions, suggestions, opinions and instructions.  It all gets mixed together with no clear accountability and tracking. If you later go through a chat log it is very difficult to determine what should go into the issue log, assumptions log, risk log or decision register. There is a risk of an off the cuff suggestion being interpreted as an instruction and costing the project time and money. There is also a dangerous tendency to assume that if no one disagrees with a suggestion then that is proof of a consensus. Chat logs cannot be referenced later, it is not a real project record that can be archived. Traceability is an important aspect of project controls and the more project issues are discussed on WhatsApp the less of a documentation trail there will be.

Everything becomes urgent

In a normal project progress meeting, you can prepare beforehand with data, minutes of the previous meeting and reports. You have time to think through your response and you can choose how to present information in a way that creates the correct context. With WhatsApp group chat there is pressure to answer questions immediately, especially with how the notification system works. This is similar to being asked to respond immediately to a complex question in a meeting you did not prepare for. Immediate responses and time pressure usually leads to of badly thought out ideas, shallow analysis and lack of consultation. Projects should be schedule driven and follow the sequence of prioritized activities.  If every query, statement and suggestion requires an immediate response then everything starts to feel urgent and the idea of following a prioritized list of tasks starts to get lost. Lack of prioritization kills schedule driven thinking within project teams. It also complicates risk analysis if every issue must be given equal attention regardless of its impact on project objectives.

WhatsApp is the perfect distraction

Full attention is required to do great work. That means putting away potential distractions and focusing deeply on the task you are performing. Most project tasks are time sensitive and unique in nature so require even more concentration than something routine. Several studies have shown that multitasking reduces the quality of work. WhatsApp group chat is an obvious impediment to deep work because it creates constant distraction throughout the day. You can mute the discussion but unlike email, team members expect immediate responses to WhatsApp queries. The knowledge that there are messages pilling up, all requiring immediate attention creates a mental load and makes it difficult to concentrate. Unlike email there is no subject line to let you quickly know what the message is about, you have to read the whole thing. The other challenge with using this tool is that your work chats are in the same app as your private ones so it becomes very easy to procrastinate and dive even deeper into the distraction well.

Before embedding technology into your processes think about the cost. These group chat applications can be effective in some narrow situations but they should never be the default mode of communication.

Kabelo Bitsang holds the position of Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw

Does a Project Manager Need to be a Subject Matter Expert?

Victor
Victor Marathe, Consultant, InnoLead Consulting

“Does a Project Manager need to be a Subject Matter Expert?” The general nature of this very commonly debated question presupposes that the honour of subject matter expert is bestowed to only those predominantly inclined to the technical domain. This presumption tends to relegate the project management function and any other management function for that matter, to an offshoot of technical disciplines, and that the project management function can be performed effectively and well with only basic project management knowledge, or none at all. The question also presupposes that without being a technical subject matter expert one cannot be an effective project manager.

The general definition of a subject matter expert is an individual with a high level of knowledge, skill and expertise in a particular subject, topic and/or function.

Considering this definition of subject matter expert, we must first acknowledge that every function, topic and/or domain, therefore, has subject matter experts in their own right. This, therefore, supposes that a project is executed by various subject matter experts. For instance, a typical project team will comprise of technical, project controls, and project management subject matter experts to list but a few.

My colleague Pardon Baleni previously pointed out in his article “Do Engineers Make Great Project Managers” (12.09.16) that the skill set required of project managers is distinctively different and broader than the skills set required for an engineering function. With that in mind, the question “Does a Project Manager Need to Be a Subject Matter Expert” becomes a dead end question. That is the correlation between the two functions is not as absolute as to allow for a Yes or No response.

However, it does prompt for the contextualization and qualification of the two functions and how they fit in the project structure.

This article will thus deviate slightly from presenting arguments for and against the question at hand, but will rather focus on contextualizing the roles of the two functions and how and when they more appropriately fit in the project structure. We shall leave the reader to then form their own conjecture on the question.

Product Subject Matter Expert vs. Project Management Subject Matter Expert

The two Subject Matter Experts under discussion are not mutually exclusive and it is also not a given that being a product Subject Matter Expert qualifies one as a Project Management Subject Matter Expert and vice versa. Both are however critical to the success of a project.

The two Subject Matter Experts operate at different levels of the project and the emphasis is different depending on the type, complexity and phase of the project.

Let us consider the typical project work breakdown structure (WBS). There are two major levels of the WBS. The principal deliverable level and the work package level, which is made up of the secondary deliverables. Generally, the principal deliverables level is decomposed to a level 2 of the WBS and can be developed with resources with a surface level knowledge of the product, but above average project management knowledge and experience.

Level 3 downwards is more detailed and makes up the work package level or secondary deliverables level. To compile WBS deliverables at these lower levels more product knowledgeable resources are required. These are the product and technical subject matter experts.

From the above departure point one we can assert that a Project Management Subject Matter Expert is one who is an authority in project management process and hence is more suited to manage the higher levels of the project WBS. That is, manage the project development cycle.

The Product Subject Matter Expert is one who is knowledgeable in the development and function of the product for which the project is being executed. The Product SME is, therefore, more suited to manage the product development cycle.

The next lower level subject matter expert is the technical or discipline subject matter expert. These are individuals who are knowledgeable and skilled in single stream elements that make up the product i.e. electronics, mechanical, software development etc.  These individuals operate and manage the lowest level of the WBS.

In simple terms, the project manager manages the project execution process and product or work package manager manages the product development process. For which it is a subset of the project development cycle.

This is not to assert that one set of skills and or knowledge is more important than the other, but rather to qualify that in the continuum of required skills in the project execution process, the required skills differ for the different levels of management.

It is also worth noting that depending on the size and complexity of the project there could be several layers of project managers and different levels of the project structure. This means that product and technical level operatives on a project could be required to execute project management functions within their sphere of influence on the project scope. Has the assertion that the skill sets are not mutually exclusive but rather complementary and essential for both functions.

Project Management Skills vs. Product Development skills

Project management is no different from any other form of management. Besides understanding the project management cycle, the project manager has to have a keen understanding of managing people, resources and integrating all project management processes to ensure that the overall project is delivered within the set parameters. In short a global management view of the project. This is not a skill that occurs by default as a result of being an experienced product or technical subject matter expert. It is a skill that has to be consciously and deliberately developed and cultivated to become a project management subject matter expert.

The product and/or technical subject matter expert is more technical inclined with lesser emphasis on the global project. The focus of the product subject matter expert is on the technical completeness, functionality and quality of the product.

The dominant perception that needs to be challenged is that subject matter experts naturally evolve into project managers without deliberate project management development. This common misconception more often than not results in catastrophic project failures but is often not acknowledged as the anchor cause of project failure.

On the other end of the continuum we must acknowledge that there is benefit in the project manager having some level of knowledge and skill relevant to the product being developed by the project, but it is less of a potential for project fatal flaws in the absence of such knowledge than the potential for failure presented when the project manager is a product subject matter expert without project management expertise.

One can, therefore, assert that being a technical subject matter expert does is not a prerequisite to being an effective project manager but rather that it is more ideal that one is a project management subject matter expert to be an effective project manager

The depth and breadth of the knowledge and skill should be in line with the complexity and risk associated with the project.

A project manager needs Product and Technical Subject Matter Experts to produce a quality product and to ensure a well scoped out project and execution plan.

Product and Technical Subject Matter Experts must follow a deliberate development process to evolve into competent project managers.

The evolution into a project management specialist is not a natural evolutionary process, it has to be as deliberate a process as the process of evolving into a technical subject matter expert.

Victor Marathe is a  Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw

Your project needs more pessimism

Kabelo
Kabelo Bitsang, Consultant, InnoLead Consulting

Optimism is like vitamins. It should only be taken in small targeted doses, otherwise, it will poison the host (or project in this case). The glass-half-full positivity championed by self-help gurus and motivational speakers can quickly damage a project team by encouraging them to ignore reality and fail to react to the inevitable changes of project life. Trying to create an environment of “positive thinking” within your team will often lead to ineffective project management.

Optimism Bias –A human weakness

Psychologist Daniel Kahneman defines optimism bias as the human tendency to overestimate our abilities required to perform a specific task and underestimate the complexity and duration of the task in question. He believes that optimism is the biggest flaw in human decision making. Scientific studies have shown that our brains are wired to produce hope. This was useful during our evolution but can create management problems in the complex modern economy.

The optimistic planner is a bad planner

During the planning phases of projects, optimism can be harmful in several ways:

  • Lead to underestimation of the duration of tasks by dismissing the possibility of delays
  • Lead to you falling in love with a certain option and ignoring its pitfalls
  • Lead to you underestimating the complexity of the project, especially the interactions between different systems or processes.
  • Presenting the best case scenario as the most likely scenario to decision makers and stakeholders.
  • Failing to put mitigations in place for risks because the risk event is seen as unlikely
  • Agreeing to superficial deadlines not driven by a schedule or the realistic sequence of events

The optimistic project manager ends up managing by crisis

The optimistic project manager is very slow to react to issues because they believe that they will magically resolve themselves. You cannot solve the problem if you do not even acknowledge that there is a problem. Team members who point out potential problems will be seen as negative and lacking faith in the project. If you surround yourself in a positive thinking bubble, when it bursts it will seem like the sky is falling. You will go through shocks that other people easily saw coming. Minor issues seem earth shattering if you spend your time ignoring reality. Project Earned value metrics are supposed to act as early warning indicators but to an optimist, they are just an annoyance. Good project managers love bad news so do not let your optimism get in the way of receiving useful information.

Defensive Pessimism

Embracing pessimism does not mean celebrating failure or being ruled by fear. It also does not mean lacking confidence in your team’s abilities. Defensive pessimism is an approach that involves setting low expectations, assessing possible risks and setting up early warning mechanisms. This is a much more effective approach than irrational hope and confidence about the future driven only by positive thoughts.

Kabelo Bitsang holds the position of Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw