Author: Ambadapudi Sridhara Murthy

Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He is a Project Management Professional (PMP)® credential holder, PMI Scheduling Professional (PMI-SP)® credential holder, and has delivered projects over a wide range of domains, such as Leak Detection Software, Pipeline Hydraulics, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of project management and consulting/software services. He earned his bachelor’s degree (B.Tech) in chemical engineering from Pune University, India and earned his master’s degree (M.Tech) in computer-aided process and equipment design from REC/NIT in Warangal, India.

The influence of efficient projects, skilled project managers and quality reporting on Digital Transformation

We know the world is moving through a rapid digital transformation phase wherein various organizations, companies, industries, institutions, and governments are transforming their processes, infrastructure, applications, software products, design, testing, customer management, and other elements into a more robust, automatic and sophisticated foundation to keep themselves business and customer-focused, progress faster with cutting-edge technology and march ahead of their competitors in this disruptive and advanced digital transformation journey. While we talk about all these so-called businesses digitally transforming themselves, we are referring to so many changes or advancements that are taking place internally within those businesses under the umbrella of ‘digital transformation’. Each of those advancements mostly starts with a strategic idea in the direction of transformation aimed at long-term growth, gets converted to a requirement, and then moves on to the fast-paced design and implementation depending on the respective domain and industry where the strategic idea is born. If we break this down into smaller pieces, at the end of the day, each implementation of a digital transformation element is eventually a ‘project’. While all these digital transformations are executed ultimately as a project, it is also worth noting that in this process, even projects, project managers, and project reporting are also getting transformed into more innovative, cutting edge and erudite resources or execution processes thereby becoming the most prominent factor and the vital launchpad for the success of multiple digital transformation journeys. This article throws light on the several variations, enrichments, and successful challenges that projects, project managers, and project reporting have been and are going through implicitly while also driving and strongly influencing the successful execution of several digital transformation initiatives in a global and competitive environment.

Talking about projects and project executions, gone are the days when manual copies of project contracts and other documentation were filed and protected throughout the duration of the project. Project processes are now digital, automated, and saving a lot of administrative time. Project creation, assignments, tracking, and monitoring all happen through various automated tools and applications. These management tools are also web or network-based such that these can be accessed and updated by a project manager (PM) irrespective of where the PM is located.  Digitalization has revolutionized the project execution processes to be implemented in a completely remote manner without the need for a team to be physically present in one location. Communication channels, stakeholder meetings, project testing, and training are all web-based thereby removing the barriers of physical presence and additional admin time to be invested in projects. These progressions and reserves also indicate and prove that cost saved is cost invested in executing more projects than was the case before – which fundamentally means that with the advent of digitalization and automation, more and more strategic ideas and hence projects will get successfully accomplished at less cost and with more automation and innovative execution techniques. This transformation of projects (at the ground level) is the vigorous and the most effective instrument that plays and will play a key role in the larger picture of implementing scalable digital transformation programs within giant organizations.


The main drivers or the pilots for the progress, execution, and success of digital transformation projects are the so-called “Project Managers” (PM’s).  PM’s have themselves automatically transformed over the years and with the dawn of automation, artificial intelligence, and cloud technologies, PM’s have found their competent ways of getting projects executed at a much faster pace without an impact on the quality, timeline, and other relevant execution parameters. In other words, PM’s have become more agile, are using technologies for quicker and effectual monitoring/tracking, and executing more projects in parallel than a year or two ago. Thinking in the grand scheme of things, it would be more apt to say that PM’s are spending less time on individual projects but still delivering them within the boundaries of scope, time, cost, and quality and have also transmogrified themselves into a state where they are executing more projects than before within the same amount of time – which means more transformations (or transformation projects)  are actually getting executed at the base level, resource usage is optimized, revenue generation is at its maximum possible thereby putting organizations on a growth trajectory in this intense, disruptive and competitive transformation journey. It is also to be noted that while PM’s in the era of traditional project management were only focusing and executing projects strictly based on a set of quality processes and procedures, PM’s in the digital transformation era are following a combination of “technology-processes-automation” to fast track multiple areas of the project thereby increasing delivery efficiency, decision-making and creating/releasing additional free-time to be utilized on other transformation projects.  The combination of automation and technology has been a boon in disguise for the PM’s in recent years due to the fact that these two elements take care of the intelligence that needs to be analyzed in the back end and presenting the most valuable decision making information to the PM’s – thereby saving more time for the PM who otherwise would have to spend a lot of mechanical effort to decrypt the available data and convert it to a form that can be analyzed easily. This in turn also helps the PMs (and hence the organizations) to focus more on the big challenges (farming out the labor-intensive repetitive work to the automated intelligent tools) or the problems hindering the transformation, come up with effective analysis and decisions, and deliver products/value to the customers at a faster pace and with very little time to market.

Figure1: Traditional Vs Transformed Project Execution

One other important element that measures the success of these transformations and the accuracy of mechanisms used for execution the digital transformation is the financial and other reporting that comes out of this “technology-processes-automation” combination being used by PM’s and organizations for digital transformations of all sizes. For any program or a project (large or small), organization always need some kind of a measure to check whether their project (and or investments) is progressing in the right direction and or need some kind of a corrective action(s) to be implemented in case of deviations from the growth path. It is for this reason that PM’s and stakeholders always have a continuous feedback loop based on measurements coming from automated tools. These measurements contain vital information about the various project financial and non-financial reporting which give the stakeholders enough food for thought on what’s causing the current issues (if any) and/or if something is going to cause panic in the future. It is to be noted that though there are a lot of non-financial reporting parameters that could have an impact on the overall progress and hence on decision making; it is also evident that at the end of the day all of these parameters eventually impact the financial numbers associated with the project progress or execution or results. It is not always the profit that the project should aim at but also on the value or the projected return on investment that’s expected from the digital transformation. It is here that the automation/tracking of all the financial information comes in handy and serves as the most important instrument for PM’s and stakeholders to review how and which direction are the transformations going. Organizations are and should make more investments in this space as these metrics and reporting drive the easy decision-making when it comes to actually executing transformation projects. Day by day, it is becoming clear that projects or organizations that are zooming fast through the digital transformation phase have these automated financial tracking tools in place aiding them through each step of the transformation and providing them immense information on how their investment will be yielding them a much-enriched return in the years to come.

In Summary, the three dimensions of projects, project managers and project reporting together with their fast-paced evolutions are a vital ingredient to the progressions of the digital transformation journeys. While success of digital transformation journeys may vary based on domain, technology, and other aspects, it is worth noting that these three elements may form the foundation of most of the transformation journeys when we look at it from a bottom-up approach. A concept without a clear execution path or project, without a central focused leader (PM), and without measurements of the progress could lead it to failure and confusions. To add, it is also evident that in the recent years, these three dimensions have taken leaps and bounds in their specific areas and have embraced “technology-processes-automation” combination to such an extent that any projects or transformations that are built around these dimensions have a higher success rate – due to the fact that these combinations not only have the ability to automatically analyze and report, but they also provide a very high value in enhancing quality decision making which is the key to resolve bottlenecks and spearhead the digital transformation projects onto their completion, success and growth trajectory.

Does People Behavior Impact Projects? How? And what do we do about it?

We all know that projects are considered successful only when they are completed within the boundaries of scope, time, cost and quality. Bad project management is detrimental and can be very difficult to deal with – for especially large projects that involve a lot of money. A small percentage of several projects undertaken across the globe are really successful. Projects do get completed and closed but not necessarily are considered successful due to cost or schedule overruns – cost overrun – being the most common cause for project failure. Therefore, it is imperative that organizations employ better ideas and novel methodologies and frameworks in managing projects.

People behavior is one of the KEY factors that drive successful project management. In today’s world – virtual project teams often not co-located – are commonplace. In this environment, it is essential that behavior, emotions and culture be well understood by project managers.

Traditional Project Management methodologies revolve around sound technical and procedural factors: Scoping, Scheduling, Budgeting, Quality Assurance & Control, Risk, Communications and Procurement; and they all have very well established frameworks. Even with all these well established methodologies and frameworks, we just don’t seem to get project management right.

If you just thought “there MUST be something that is NOT well-documented or frame-worked well enough yet”, you have just arrived at the right place! The core of project management is – PEOPLE – around which all other processes revolve and interact.

murthy Aug12 IMG01


People centric project management emphasizes that project management should be based on Experience, Dynamics, Human Psychology rather than solely on Processes. Wise project managers focus on learning and understanding how people function in an organization – both as individuals – and as a team. It is important to figure out during project initiation how people in the performing organization behave and adapt.

Human Psychology should also be considered as an integral part of Project Management. Technical knowledge and following standard processes is one aspect but that is only 30-40% of day-to-day activities. We need to better manage the remainder of the 60-70% – which is people centric.

The aspect of projects that gives project managers sleepless nights is people behavior – especially factors emerging from them – such as push-back, resistance to change, acceptance, trust etc. There are several real life scenarios project managers encounter – that emanate from these aspects. Project managers are encouraged to implement people centric management techniques that will eventually will help them implement processes as well as manage behavioral aspects of people successfully.

People centric project management differs from traditional project management in that it does not reject the basic principles of traditional project management but in addition, it emphasises that all traditional project management processes be followed as usual but be tailored according to the need in order to reap rich benefits coming from good people behaviour being exhibited as part of the project implementation.



The most important factor coming from humans including sensitive aspects is Culture. The term culture means different things to different people. From a project management perspective, culture simply means “how is stuff done here”. Culture is something that comes with people as a baggage along with them. It is imperative that a project manager understand and interpret what the culture of the performing organization is. This becomes increasingly challenging with virtual global teams. When a team member responds swiftly “It is impossible for us to carry out this work” without analyzing the work assigned – it is likely that employees are striving within an organizational culture that is not supportive of their efforts!

murthy Aug12 IMG02

  • Study: People will likely not understand this concept at the outset – since PCPM focuses on how people function and how they apply project management to be people centric. Managing triple constraints (Scope, Time and Cost) is the objective of healthy project management. However, it needs to be understood that this does not happen in isolation. This happens in a colloidal medium where people see each other, talk together and interact with others. It is crucial that project managers don’t curb or belittle Emotions, Politics, People Dynamics. Instead, they should be seen as the arteries and veins of human life and we should be able to better manage them.
  • Analyze: How you go about implementing PCPM varies from one organization to another. It needs to be a part of the organizational strategy. Organizations would be project based – where large parts of the workforce is involved in multiple projects. Analyzing how the organization is structured helps the project manager make some of the most important people related decisions in an effective manner.
  • Adjust or Adapt?: Most project managers tend to enforce processes without understanding the culture and capabilities of the project team and stakeholders. In PCPM – focus should be on adjusting processes to fit the culture and behavioral responses rather than trying to adapt human nature to follow processes. Adjust the role and processes for people – do not enforce processes on people.
  • Propose Changes: Create a governance committee or steering committee that is part of the leadership team. Ensure that the PMO, Senior Management are on board and devise a strategy on how you will move from rational to behavior centric project management. A roadmap needs to be laid to bring about either procedural or cultural changes. In 99% cases, people work in environments that Resist Change. So, what is new with PCPM? In PCPM, project managers must educate the senior management, team and stakeholders of considering people behavior while planning each project phase of the project.
  • Gain Buy-In: The challenge for most project managers is to work with senior management and the team in tandem, to gain buy-in and decide on adjusting or adapting. Adjusting or adapting does not happen overnight.
  • Implement (Kaizen): PCPM will not happen overnight but will require a cultural transformation. PMs should quickly identify strengths and weaknesses of team members and encourage people to identify their strengths and work with their strengths. Some people will have competitive strengths and it is important to leverage their competitive skills. Project managers tend to polish people and make sure people fit the role instead of adjusting the role for people.
  • Introspect: It is essential that project managers introspect how PCPM is being implemented. The introspection frequency will depend on several factors such as the team size, stakeholder size, location of teams and stakeholders, senior management demands etc. Introspection is the only way of answering the questions “How are we doing today? Will we be able to implement PCPM? What else needs to be done to strengthen the PCPM process? How long will it take for people to be on board? etc.”


Engaging project team members is the foundation to project success. In PCPM, it is extremely important that the groundwork be laid to engage team members and stakeholders and finally sustain in the short and long term. Focus should be setting key performance/productivity indicators for the performing team as a whole. The level of engagement of team and stakeholders should be monitored and strategies be devised to maximize the engagement levels of both at the same time. Performance, Productivity, Efficiency and Efficacy must be maximized or at a minimum balanced.

Across the project lifecycle, engagement levels of individual team members and the team as a whole should be monitored. Emotional and personal expectations of the team members must be addressed to bring about the best in them. Questions such as “How is this individual doing on the current project?”, “How does this employee react to his work load?”, “Does the employee feel good at the end of every day’s work?”, “Does the team connect their personal objectives with project objectives and organizational objectives, in turn?”, “How is the project team doing as a whole?”, “How are we engaged as a group to meet our objectives?”, “What do stakeholders/customers think abour the project team?” etc. – must be asked and answered satisfactorily.

At the Senior Management Level or at a PMO level (if a PMO exists), it will be important to update or change the overall project management framework to integrate all the knowledge about human nature and the questions answered above. Tools must be developed or customized to measure the level of engagement of teams or stakeholders accurately. These new tools must be integrated into the new project management framework.

Finally, the new approach of People Centric Project Management (PCPM) should be reflected in the overall PMO’s strategic objectives and long term vision/mission.


Emotions have to do with hormones and neurotransmitters in the human body. Emotions drive employee motivation positively or negatively. Oh boy! Isn’t it difficult to psycho-physio-bio-logically scan a person’s mind and body to anticipate what the Expressions, Feelings, Body Language, and Actions he or she may exhibit e.g.– they are sometimes Happy, Sad, Angry, Excited, Tender, Scared etc. This has been a long standing challenge for most people managers, especially project managers!

Feelings, Moods and Actions affect the manner in which team members and stakeholders carry out their work on projects and so management of emotional aspects is supreme for successful project management. A good project manager should not just be a technical person but should be a rare breed of individual who should be able to manage both the technical and emotional factors. If both factors are not managed, projects will cost way higher than what they are originally planned for! e.g. a strong skilled, high performing employee with tremendous knowledge (not shared with anyone else on the team) exhibiting negative attitude and emotions may not only choose not to perform but also may become a project manager’s nightmare if he decides to not co-operate.

Little attention is devoted to emotional factors in traditional project management – project managers must realize that this is the key reason for project failure! E.g. when we conduct lessons learned for failed projects, we focus only on the project management methodologies followed or those that were not followed – but we hardly attempt to identify the lack of focus on the management of the emotional and motivational aspects of people.

To ensure project success – PCPM might be a critical factor that needs to be looked into and implemented so that project managers are allowed to exhibit strong people skills and vibrant emotional intelligence!

murthy Aug12 IMG03

There is advantage to project managers being assigned to a project during initiation and PCPM reinforces just that principle.

In ensuring that project teams will get better and provide maximum output, the following steps are recommended:

✓ Select & Recruit Team members keeping in mind the new PCPM framework, project and organizational objectives.
✓ Develop Team based on PCPM framework, keeping in mind the culture of the team on boad – here we again stress on adjusting processes vs adapting!
✓ Motivate Team keeping in mind Emotional factors. More about the impact of motivation below is discussed. Emotional stability would ensure project success.
✓ Periodically Introspect behavioral responses of the team members – understand that PCPM framework needs to be iteratively fine-tuned and optimized.

Project team members or stakeholders do NOT work in an environment where they feel threatened, insecure or disarmed. Productivity is at its lowest when there is no trust and people don’t feel comfortable. If people don’t have confidence and passion for the work that they do – it does not bring about the best in them.

How is this addressed? Here is a simple question that will help us understand better

Q: So, we all know from the laws of Physics that Force = [Mass] x [Action].Here, Mass refers to people and Action refers to project success. So what is the force then that needs to be applied to people to achieve project success?

A: Motivation!

Motivational factor in knowledge based industries (IT etc.) is important and is desperately needed in PCPM. Project managers need to look at alternative ways to look at projects as a social system rather than a technical system.

From an organization perspective, projects entirely involve around costs, risks, frameworks, internal/external market scenarios, decision making, harnessing talent, identifying critical resources etc. With virtual global knowledge teams working in different time-zones across different projects at the same time, it is very important to ensure that people stay motivated and magnetized to a specific project. PCPM becomes a guiding methodology in this dynamic environment and proper motivational drivers are a MUST. This helps get people focused on one project and give it the priority it deserves.

There are several motivational theories that can be applied in the PCPM framework but it is important to consider Motivation as one of the key drivers.


Behavior refers to the range of actions and mannerisms exhibited – in this case – by people. Certain desired behavior is assumed by project managers when they stitch and integrate several of the established project management processes. This assumption is based on factors such as Culture, Attitudes, Emotions, Perceptions, Values, Ethics, Authority, Rapport, Hypnosis, Mindset and Persuasion, among others.

On most occasions some of these assumptions don’t hold quite valid. When people don’t behave like the way we originally assumed them to, their behavior seems unpredictable to us. And, when people behavior becomes unpredictable – project outcome is inevitably affected – either positively (success) or negatively (failure). Even if project managers don’t forget to include people behavior, they may find out that the people in the system don’t behave as expected, with unanticipated project outcome.

Think of the human brain emitting encrypted signals. Most project managers intercept these signals but hardly a few actually decrypt and interpret them. This act is called Intuitive Mind-Reading!

The ultimate goal of project management is to ensure project success. As part of PCPM, project managers MUST sharpen their mind reading skills and identify potential Known Behavioral Risks that may emanate from ALL people involved (team members, stakeholders, bosses, senior management etc.) in the project and adapt to this behavior to ensure that things that can go wrong don’t go wrong. Successful project managers are gifted with Intuitive Mind-Reading. During project execution, project managers must reach out to all these people involved, observe what tends to go wrong – and ensure it doesn’t.

Is Intuitive Mind-Reading the only tool for identifying behavioral risks? Not necessarily but in most cases, Yes! E.g. it is best to begin with analyzing our own behavior and from there extrapolate and extend our understanding to all types of people behavior across the team.

However, in other cases where Unknown Behavioral Risks show up during project execution, it is the skill and brilliance of project managers that helps them better manage the situation and drive towards project success.


The real problem of projects is NOT the planning or technical aspects but is the day to day contact with people – which is the major nightmare and poses the biggest challenges to project managers.

At any given point of time in the project lifecycle, there will likely be hundreds or thousands of communication channels across project team members and stakeholders. These channels provide the opportunity for people to exchange information among one another. Whether it is Email, IM, Meetings, 1:1(s), Reports etc. it is important to question – what percentage of these channels actually yield positive and fruitful interactions? This will be a key indicator for project success. Project managers need to create a conducive environment for nurturing positive people interactions.

As always, you need the right blend of people in your team to talk to the appropriate stakeholders, gain buy-in and work along project integration. Once you have the PCPM thinking in place, then the next step is to focus on the project team.

In PCPM, it must be the daily duty for project managers to maintain the line of communication very open so that they keep catering to the basic needs to employees.

What needs to get communicated across and top things project managers need to keep in mind while implementing PCPM?

  • Understand and believe that project managers have the most impact in opening up communication channels.
  • Communicate what is expected of each team member
  • Establish a clear sense of what each team member’s duty or role is.
  • Provide recognition – this is actually part of communication!
  • Empower team members’ with the right tools and techniques to do the job
  • Keep your ears open to suggestions
  • Have open conversations about every aspect that requires the PCPM framework to be adjusted.
  • Frequently talk to team members about their progress and provide feedback –
  • Learn from people on how they think they connect to the mission of the project team and compare that with how you think they connect.
  • Communicate between the current statefuture state the gap  and how is the team member is doing.
  • Make Action Plans for the longer term to ensure you are actively managing the emotional and motivational aspects of ALL the people
  • Gather feedback and inputs on how are people interact with each other on their communication channel.
  • Finally, it is the project managers duty to ensure that interactions on ALL communication channels yield positive results!

The key truly is communication, communication, communication and communication!


If organizations want project managers to deliver projects perfectly, that cannot be done solely by following a rule book, using project management software, firefighting problems, implementing the concepts from PMBOK etc. Project managers MUST also be able to manage the thousands of interactions people have within the project and outside of it (environmental factors). The emotional bonding between individuals must be well understood and recognized to get the best out of the people. This ultimately is crucial for achieving proper level of teamwork, communication and performance that is needed for successful project management.

In addition, because our society or organization is not good at working with the behavioral and emotional drivers, we cannot motivate people to complete the project on time, cost, scope and quality. Aspects of project management dealing with people, behavior, emotions are not much stressed upon. In most documented areas, either it is in a footnote or in an appendix.

To conclude, emphasis must be on the importance of people behavior and having a framework such as PCPM – in place to account for people behavior – as an effective solution guaranteeing higher project success rates!

Don’t forget to leave your comments below.

About the Authors

SreenivasShreenath Sreenivas, B.Sc.(Hons.), M.Sc, PMP has in-depth knowledge and experience in software project planning, integration management, requirement gathering, risk management, scheduling, vendor management, contract management, execution, monitoring, controlling, quality assurance and on-time delivery. He is a Project Management Professional (PMP)® credential holder and has delivered projects successfully across a wide range of domains, such as Pharmaceuticals, Bio-IT (LIMS), Tax and Accounting, Mobile Web Apps; in addition to the field of software product development and consulting. He earned his Bachelor’s B.Sc. (Hons) & Master’s M.Sc. degrees in Industrial Chemistry from the Indian Institute of Technology (I.I.T.), Kharagpur, India.

MurthyAmbadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He is a Project Management Professional (PMP)® credential holder, PMI Scheduling Professional (PMI-SP)® credential holder, and has delivered projects over a wide range of domains, such as Leak Detection Software, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of software services. He earned his bachelor’s degree (B.Tech) in chemical engineering from Pune University, India and earned his master’s degree (M.Tech) in computer-aided process and equipment design from REC/NIT in Warangal, India.

Using “Work Breakdown Structure (WBS)” for Effective Project Estimation

murthy June17Thinking about projects and project execution, the competition in this world has become so huge and intense that organizations hardly want to take any risks that might place their projects within the zone of penalty and negative implications during any phase of the project/program. Having said that, because of the accumulative bunch of free project tools and process knowledge available out there today, organizations also take the necessary corrective actions upfront to ensure that all of their programs/projects are fully compliant from a process, quality cost, time, scope and schedule perspective that are much compulsory to meet the delivery demands of the Client/Customer in this progressively challenging project galaxy across the globe. Of the factors mentioned above, let’s take “Scope”. Scope is the core need for all projects – this is the real thing that needs to be understood and implemented for the project. As we all know very well, there are several circumstances across the orb wherein projects have failed or have went into losses for the simple reason of the scope either not being correctly understood or not being correctly implemented on both. “Scope” is the connecting factor for the rest of the project parameters of cost, time, resources, etc. and hence getting to understand scope, breaking it into smaller pieces, creating simpler scope tasks, and confirming the associated project deliverables is the key for any project. This article describes one of the most important tools – the WBS (Work Breakdown Structure) for understanding and decomposing project scope and also the various advantages/successes that a project team could derive if a WBS is well-prepared and used through the duration of the project.

What is a work breakdown structure?

Simply put, a work breakdown structure is a hierarchical decomposition of the scope/work that needs to be estimated and executed during the course of the project in order to accomplish the project objectives and deliverables.

Though it sounds so simple, a WBS has enormous strength and influence to convert complex requirements/scope into small and easier pieces for project estimation, planning and execution. A WBS: 

Related Article: Project Risk Management in 12 Questions

  • Gives Clarity on the project needs in terms of deliverables and success criteria – it highlights the “what” of the project
  • Organizes the project scope, puts a defined decomposing structure around it
  • Gives more simplicity and break-up of the activity to be performed using its each hierarchical decomposed level
  • Successively subdivides the scope into manageable components in terms of size, duration, and responsibility
  • Is a structured diagram portraying the hierarchical listing of overall project requirements into increasing levels of detail
  • Aids in assigning responsibilities, resource allocation, and monitoring and controlling the project
  • Is an important instrument for reviewing the decomposed scope (with defined deliverables) with the project stakeholders. It also gives a meaningful pictorial view of the scope and deliverables of the project.

How to Create a WBS and what’s its importance?

Step1: List out the Highest Level requirements / Scope Deliverables

It’s one of the most common practices that the first scope statement or the scope of work that a project team receives might contain information in a mix-up format and hence it cannot be taken as-is and used for project estimation and implementation. The project team needs to discuss the scope with the Customer/ Customer analysts/system users to understand the need of the scope mentioned and also the main objectives/requirements/deliverables that are expected out of the project. It’s implicit that these requirement clarifications and discussions with the Customer teams are required throughout the course of the project as and when required from an estimating perspective. Place these objectives/requirements/deliverables at the first level of hierarchy in the WBS diagram (See Figure 1). This step gives a defined starting point to the project estimation process by converting a scope document into a first set of high level requirements. One of the points to keep in mind is that developing a hierarchical diagram is only for ease of understanding and quicker understanding of the scope decomposition. The broken-up components can be listed and numbered in any format and in any tool (Word, Excel, MPP, etc…) and can be tracked in various ways. It is not the format that matters but the connection and linkage between the parent and the child scope items that make the WBS structure one of the most prominent and useful tools for the process of project estimation.

murthy IMG01

Figure 1: High Level Requirements

Step2: Break-up each high level requirement into major deliverable categories

Once the high level requirements are available as defined in Step 1 above, for each of the high level requirements, teams should then take-up each of them one by one and start digging into the next level summaries of what’s the product or what are the products that need to be created/changed/implemented for meeting the requirement. It will quite be possible that for a given high level requirements changes might need to be made to four different systems/components each of which could be implemented independently. As part of this step, team should keep asking itself – “what needs to be done” to achieve this requirement? One needs to be sure that the next level break-up being created should relate to products/activities that need to be defined further (See Figure 2).

murthy IMG02

Figure 2: High Level Requirements Broken-up into Sub-Categories

Step3: Break-up each major deliverable into single or multiple measurable activities

The next step is to take each deliverable/system change identified in Step2 and create defined activities or work-product(s) for each of them with the information related to the associated effort required for each of the activities together the level of risk and complexity for each of them. One thing that needs to be remembered is that as we go down the WBS structure, the activities should get refined till they reach a reasonable and measurable activity. Now the question is “what’s the rule for a measurable activity?”. I would say there is no such confirmed rule and it would mostly depend on the type, size and complexity of the project, organization process and also the level of break-up that the WBS is being built with. Normally, an activity with duration of 40 hours or up to the max of 80 hours is considered as a measurable activity as these durations are reasonable enough for a project lead or a project manager to monitor. The measurable activities thus created are sometimes termed as work packages and one of the principles of a WBS is that the requirements need to be continuously decomposed till we arrive at a final list of work packages that could be monitored. It is very well possible that each major deliverable that we started off in this step might have more work packages and in some cases, it might be needed to decompose the current deliverable into more sub-levels until a defined work package is arrived at. In that case, the WBS structure will go into deeper sub-levels which is ok since the goal of carrying out the WBS exercise is to ensure that each requirement is successfully drilled down to its respective final deliverable/work package (See Figure 3).

murthy IMG03

Figure 3: Major Deliverables broken down into measureable activities/work-packages

Step4: Review Work Packages for completeness of Scope Coverage

The final step in this process is to ensure that the correct numbering is applied to each of the levels and that each requirement is efficiently drilled down to is respective deliverable mapping all the intermediate WBS components. Each component within each level of a WBS is numbered as and when it’s created. In this step, the WBS components are reviewed from top to bottom to ensure that the top level requirement has its hierarchical deliverable numbers for each of the levels clearly listed and also ensure that none of the high level requirements or the intermediate deliverable is missed in the process. This step also ensures that the implementation of listed components or completion of listed actions will indeed lead to the anticipated results. This final listing of WBS numbering also gives a good idea for the project managers when they are creating the project schedule as the WBS gives detailed information on the predecessor and the successor activities of the each component.

Is WBS required for every Project?

I would say “yes” – But not necessarily as a mandatory requirement. It merely depends on the project needs, the organization process and the type, size and complexity of the project. Having said that, even if we use the WBS process as a standard procedure within the project or not, it is imperative that the principles of WBS are always used by anybody estimating for an important project. Otherwise, how would they arrive at the estimates? If it’s by mere trial and error, the, chances of project failure are extremely high. In other cases, it’s just that the standard process is not explicitly followed, but the implementation team would definitely have arrived at an estimate by implicitly making certain decisions based on the goals of the project that need to be achieved, project risks, expertise, past experience, the organization’s process compliance and the project constraints. As mentioned before, WBS is just an instrument or a tool to decompose a large or a hypothetical scope into a set of definable, structured and measurable activities or tasks that are associated to the respective project deliverables. To add, since a WBS gives an idea of the effort required for each of the work packages together with the associated risk and complexity information, it could also be used as an apparatus to prioritize requirements or deliverables based on the effort required, risk associated, number of unknowns and complexity involved. Hence, a WBS is sometimes used as a connecting point between the Sales/Marketing and implementation teams as it aids them in making scope decisions quickly and with more precision thereby reducing the risk of losing some functionality in the system/product that would otherwise have been more beneficial to the system/product/organization.

Dos and Don’ts

Team Building Activity: The process of creating a WBS should be considered as a team building activity. For projects of normal size, a WBS cannot be created by one team member. It needs various team members to take-up each high level requirement within the given scope, discuss about it with others in the team and then each lead team members need to come-up with the activity/work-package break-up details related to that specific requirement. Likewise, the activity details are arrived at the other lead team members and the project team consolidates all the deliverables information received and collates back to a fully blown WBS which can then further be sued for the next steps of project planning and scheduling.

Not a Project Schedule: A WBS is not a project plan or a project schedule. It only provides detailed information on the given initial scope and on the final deliverables that need to be implemented to achieve the project goals and objectives. It should be understood that WBS helps in giving an accurate input for creating a project schedule by way of the activity/work package information.

murthy IMG04

Don’t go into too much Detail: Project teams typically assume that as part of a WBS creation, they need to go into details of the high-level requirement – which is correct. But one needs to understand that this drilling down of the high-level requirement should not be taken down to the lowest level of the detail which makes it cumbersome for the project team members itself to monitor and it also leads to micro-management from a project managers perspective which is not healthy for any project. Project teams should start thinking of WBS as an instrument which can be twisted to suit the specific project scope needs. There is no hard and fast rule that one needs to break-up a requirement into three levels or four levels. It is up to the project teams and the project manager to decide on the degree to which a particular requirement/scope needs to be broken-down to in order to make it meaningful and reasonable for successful implementation, monitoring and delivery. There might be some requirements that are straightforward and which would not take a couple of weeks to implement- then in that case the requirement itself can be assumed as a work package spanning across two weeks duration and the output of the final deliverable also is clearly understood since the original requirement defines it with precision.

Customer/Stakeholder Communication: One other vital aspect that projects teams need to bear in mind is to ensure that they always keep an open communication channel with the Customer/Client and the various stakeholders of the project throughout the process of WBS creation. One should not assume that since the team is breaking-up scope into smaller elements and creating a WBS, discussion with the stakeholders is not necessary – that would be one of the biggest blunders. Bottom line is that how can one break-up a larger scope into required smaller elements unless they are clear on the final product change or the functionality that is expected from the project. Breaking-up scope into smaller activities is not going to help unless one is clear on the actual output desired from the given requirements.

To Conclude, if a structured WBS process or procedure is followed, the chances of a successful project estimation, planning and implementation are much higher which would help the global project teams to minimize project risks and also benefit them from getting entangled into a unnecessary change control/scope-creep/project-delay discussions which are the some of the most common avoidable issues persisting in the project management space today.

Thanks for Reading!

Don’t forget to leave your comments below.

Top 5 Things That Need to be Considered Before Finalizing a Vendor SOW for Software Services

murthy apr8The industry today is going at such a rapid pace that organizations are in no temperament to wait for resources to be available for executing a project as any organization wants to reap rich benefits out of any project in the earliest possible time. Thus if one has an approved project with the required budget and if there are challenges with the availability of internal resources, then organizations start searching for external partners with the required skill-set in order to give a quick kick start to the project. That’s how, as we all know, outsourcing comes into the picture. And outsourcing provides add-on benefits in increased productivity, lesser costs, resource availability, earlier time to market and hence good customer satisfaction. Outsourcing, and specifically software services outsourcing, however, has its own de-merits and negative impacts if the hand shake of the outsourcing is not properly done and if the specifications of the work to be performed are not mentioned with transparency together with the penalty implications it might have for a wrong project execution. Though, for every project, being implemented by either internal or external teams, we do have a statement of work which explains the scope, type, constraints for the space of work to be performed for the project under consideration. This article focuses on the vital aspects that one (any PM or an organization) needs to take into account when writing an SOW (for a specific project) for a preferred and selected software vendor contractor who needs to be approved for implementing the given scope of work.

1. Check the Agreement, Contract or the MOU that the organization has signed with the Vendor

Before sending out an SOW to a proposed vendor, the PM and his team need to check if their organization has already entered into a relevant Master Service Agreement/Contract with the Vendor. This is sometimes also mentioned as a MoU (Memorandum of Understanding) by some organizations. It is this agreement that describes the handshake between the two organizations and also the various confidentiality clauses related to the organizations information, data and products that the vendor needs to maintain secrecy about and ensure that none of this information is disclosed to the external world without prior approval from the customer. This document is the legal binding document between the two organizations which also include the various penalty related information in case the vendor fails to adhere to the conditions or the constraints set forth within the agreement/contract. In case of a scenario, where the PM cannot find a Service Agreement/MoU/Contract with the Vendor, he/she need to contact the company’s concerned legal department to understand about any existing agreements with the vendor or if the organization needs to enter into a new agreement with the vendor prior to entering into an SOW discussion with the vendor.

The below list out the main topics that must be covered within an SOW for an organization to gain maximum benefit by awarding a project to a specified vendor

2. Scope – Project Background and the new Scope Information

Any SOW that is being sent out to a vendor should have clarity on the project background information, product or the applications (that get impacted because of the current project) related history information, technologies that the project, product or the applications are built with, a high level overview of where the project, applications and its architecture sits within the organization and what’s the new thing that will be introduced as part of the current project/SOW. A more detailed information needs to be presented for the scope of work that needs to be implemented as part of the current SOW – this should cover for the strong and specific requirements of what needs to be developed, the inputs, outputs, validations, UI, integration with other pieces, standards to be used, the end-user behavior, architecture, technologies to be used, integration process etc. It is also important to mention the type of software methodology (Waterfall, Agile, etc.) that the customer wants the vendor to use for the given scope of work and also provide clarity on how the scope of work will be elaborated and what is expected of the vendor in terms of the implementation and the corresponding impacts of time, cost and quality based on the methodology selected. It is mandatory that as much details that can be provided in this category of the SOW would help the organization to get a maximum work results as possible. Even a small requirement that’s missed here will need to be developed at an additional cost later in the future. This section should also list out the various assumptions and the dependencies that being thought of for the project – be it code, applications, projects, people, quality, time, cost people etc. – it is worthwhile that these are all evidently listed out in the SOW as well to avoid war-room discussions in the future.

3. Constraints – Technology, Methodology, Testing Considerations, Review Procedure and Penalty Conditions

Once the scope or the so-called requirements are clearly stated with details in the SOW, the information related to the technologies that need to be re-used/used for the current project need to be specifically mentioned with precision on the type, version, degree of complexity and support considerations. This is necessary to ensure that the vendor implements the project using the technology and architecture standards that are on-par with the organization and that these can be easily plugged into the current system without any hindrance to the integration, flexibility, scalability, reliability and performance specifications. Details about the process of Peer Review, Product Quality, Unit Testing, Integration Testing, Data Testing, Security and performance testing and the success criteria for the testing cycles must be clearly stated in the SOW. On the other hand, these success criteria should also be mapped to the corresponding penalties that the vendor would need to face in case of non-compliance with any of the delivery requirements by the vendor. This could also lead to the vendor having to completely re-execute the whole project with no additional cost to the customer/organization.

4. Change Control – How to handle change to the scope of the work or project

One of the most common problems heard in the software services industry even today is that there are always soft and hard communications going back and forth between the customer and the vendor over the issue of scope change and that there has been a misunderstanding of scope between the customer and the vendor which leads to a situation wherein the customer expects a part of the product as part of the defined scope whereas the vendor retracts stating that this scope was not mentioned with the SOW requirements and hence would need to be treated as a scope creep or a scope change. No just this, in such situations, any small change in scope would trigger a corresponding impact of time and cost for either the vendor or the customer depending on the direction the communication wind moves. In order to avoid the above mentioned type of scenarios, an SOW should always contain details about what would mean by a change for the work/project under consideration. It should clearly state what kind of implicit/explicit requirements would be treated as a change and if at some change is identified, define the process route that would be taken to formally approve that change request and also highlight the corresponding implications of time/cost to the project and also to the Customer/Vendor. Rules/Templates/Documents about the change control are normally included within a SOW and these explain the members of the Change Control Board for the current project and the also the process of change control that would need to be followed for a successful project execution.

5. Boundaries and Conditions – Type of Contract, Constrictions of Time and Cost and Project Extension Implications

This is by far the most important information that must be included in a vendor SOW. It encompasses the information related to the type of contract the customer and the Vendor agree to for the given scope of work. Though there are several types of contracts that exist out there, but the “Fixed Cost”
and “Time & Material” are the most common types of contracts that the industry organizations choose based on the type of the project/work they are dealing. If we think from a customer perspective, a” Fixed Price” contract is the most advantageous since it would mean that the vendor agrees to provide all the requirements mentioned for total fixed cost mentioned in the SOW including any bug fixes in the new product, penalty conditions and support the new product as per all the conditions mentioned in the SOW. Most “Vendors” therefore think twice or thrice before they agree to a “Fixed-Price” contract, since once they agree to a fixed cost, they need to abide by all those delivery conditions till the end of the scope of work. But, if you are a customer, a “Fixed-Price” contract is the one you should aim at.

The second one, “Time & Material”, as the name suggests, charges the customer for the amount of time the vendor resources spend on the project (Based on the corresponding resource per hour costs) irrespective of the amount of work completed. The “Time & Material” contracts can be time-bound as well wherein a time constraint if given to the vendor which means that the given scope of work needs to be completed within the given time-frame, no matter how many resources the vendor fields in for the project for the given time-period. And the vendor can charge the customer for the total hours that the vendor resources spend on the project within the given time frame. It is also easier to extend a “Time and Material” contract, since it’s only the new scope of work that gets added to the project and there is no need to add any new budget numbers for the new scope since the contract resource costs and contract type are already agreed upon and it’s just the add-on hours that the vendor will need to charge the customer for the additional scope of work.

An SOW should also contain information about the Payment schedules – meaning the contract should clearly state as to when and in which currency will the payments be made to the vendor based on the progress of the scope of work.

Last but not the least, any SOW, whether it’s written by a customer or a vendor, need to the reviewed and agreed by both the customer and the vendor organizations from a legal perspective, ant mutual corrections that are required need to made and then need to the formally signed by the authorized signatories of the both the parties to ensure that both the customer and vendor are now bound by a strong legal document before they start implementation of their first project promising harmonious partnership for years to come.

Don’t forget to leave your comments below.

About the Authors

MurthyAmbadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP

Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He is a Project Management Professional (PMP)® credential holder, PMI Scheduling Professional (PMI-SP)® credential holder, and has delivered projects over a wide range of domains, such as Leak Detection Software, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of software services. He earned his bachelor’s degree (B.Tech) in chemical engineering from Pune University, India and earned his master’s degree (M.Tech) in computer-aided process and equipment design from REC/NIT in Warangal, India. Mr. Murthy can be contacted at [email protected].

SreenivasCo-Author:  Shreenath Sreenivas, B.Sc.(Hons.), M.Sc, PMP

Shreenath Sreenivas, B.Sc.(Hons.), M.Sc, PMP has in-depth knowledge and experience in software project planning, integration management, requirement gathering, risk management, scheduling, vendor management, contract management, execution, monitoring, controlling, quality assurance and on-time delivery. He is a Project Management Professional (PMP)® credential holder and has delivered projects successfully across a wide range of domains, such as Pharmaceuticals, Bio-IT (LIMS), Tax and Accounting, Mobile Web Apps; in addition to the field of software product development and consulting. He earned his Bachelor’s B.Sc. (Hons) & Master’s M.Sc. degrees in Industrial Chemistry from the Indian Institute of Technology (I.I.T.), Kharagpur, India. Mr. Shreenath can be contacted at [email protected]