Tag: Requirements

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

Written by Ambadapudi Sridhara Murthy on June 17, 2014. Posted in Articles. 602 Comments on Using “Work Breakdown Structure (WBS)” for Effective Project Estimation

murthy June17 Thinking 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.

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

Written by Ambadapudi Sridhara Murthy on April 8, 2014. Posted in Articles. 4 Comments on Top 5 Things That Need to be Considered Before Finalizing a Vendor SOW for Software Services

murthy apr8 The 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

Ambadapudi 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].

Co-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].

The Project Manager Skills Gap

Written by Lisa Anderson on March 19, 2014. Posted in Articles. 4 Comments on The Project Manager Skills Gap

Fotolia 51544070 XS2 According to a recent survey, 87% of manufacturers and distributors cannot find the skills required to successful run their businesses. These results didn’t surprise me as each day I go into a client, attend a Board meeting of one of the trade associations I lead or talk with my colleagues, someone has decided to retire, a key employee is leaving for a better opportunity or my client just cannot find enough skills to fill critical project roles. It has become an epidemic.

I’ve found these are three key areas to ensuring success in proactively addressing the skills gap: 1) Retaining top talent. 2) Training & developing top talent. 3) Being on the lookout for top talent. As it seems the simplest yet is the most often overlooked solution, retaining top talent is a secret to success. How do we retain excellent project managers? Understand what motivates each project manager and start there. In order to do that, it helps to start by defining an excellent project manager. Which qualities are essential? 1) Leadership. 2) Communication. 3) The ability to synthesize data and tasks. 4) Execution ability

Leadership: Undoubtedly, there are too few leaders! Since project success directly ties to leadership, it cannot be overlooked. Who has the capability to influence others (whether in the power position or not)? Who does the team look up to? Who is willing to address the roadblocks upfront? Answer these questions, and you’ll have your answer.
Communication: One of the surprising facts that arose from the skills gap survey is that communication and presentation skills have risen in importance. Even in traditionally technical fields including project management, executives need significantly improved communication skills. Are you willing to communicate the bad news? Do you just drop it on your colleagues or find a way to bring them into the fold on potential issues and gain their input? Do you keep everyone up-to-speed on the project’s progress? Do you communicate why the project will deliver value? Does each team member understand his/her value? Do you seem interested? No one is interested in following someone who makes the project seem boring – or worse yet, isn’t able to effectively communicate to gain support throughout the organization?
The Ability to Synthesize Data and Tasks: You can be the most effective communicator; however, if the project team discovers that you are unable to synthesize the data and tasks to understand the scope of the problem or situation on a quick enough basis, you will quickly lose respect. This does not require that you perform all the tasks yourself or that you understand the topic upfront, but it requires that you are able to ask effective questions, see trends and connections and draw conclusions. Otherwise, you’ve wasted essential time and resources with nothing to show for it.
Execution Ability: Are you willing to do the blocking and tackling? Do you follow up? Request status? Provide thoughtful ideas. Help your team overcome roadblocks? Have a rigorous focus on priorities? Manage the critical path relentlessly? In my experience, I’ve noticed that those who have a great ability to execute appreciate solid leadership. Thus, why leadership is #1 – it will create a success loop.

So, now that you’ve identified these skills, you need to find and retain top talent. First, open your eyes. During the last few years, I’ve seen some of the best resources go unnoticed or unappreciated. Forget about the fancy three-ring binder reports and interesting conversations about the latest fad and take a step back to see who is delivering results in your organization. It might surprise you. Once you find this person, retain him/her. It all depends on the person – some people appreciate a simple thank you. Others appreciate interesting work. Yet others appreciate the recognition of their value and autonomy in decision-making. Sometimes it’s as easy as supporting their decisions – how hard is that? And, remember, the bottom line circles back to leadership.

Next, depending on what you find within your organization, search for this talent in the market. Executive recruiters are saying it’s a tough market to find high-skilled resources. Instead, you must be diligent. Do not settle or hire the less expensive resource and hope for the best. This strategy will not deliver the results required to succeed. Typically, relationships and personal connections are your best source. Invest the money in a top executive recruiter – it isn’t expensive if you think about the lost time and money wasted on not delivering results. Do not give up! If you are the leader with access to excellent project managers, you will have a leg up on the competition and deliver exceptional bottom line results.

Don’t forget to leave your comments below.

How Do You Plan for the Uncontrollable?

Written by Richard Lannon on March 19, 2014. Posted in Articles. 7 Comments on How Do You Plan for the Uncontrollable?

Businesses can be impacted by many circumstances. Often these circumstances are from external forces at play that need to be understood. Recently, while working with a client we discussed a number of challenges that the company was experiencing. We talked for some time about external events that the company was aware of but could not control.

The uncontrollable business events included an aging population and workforce, the availability of self-disciplined and skilled resources, tax law adjustments, Canadian and international industry regulation changes, the happenings in the global economy in Europe and the USA, the Canadian banks’ financial treatment of midrange Canadian businesses, the natural resource market’s price volatility, access to private investments, Manitoba’s diverse economy, technological changes in the industry and the list went on and on.

To work with a midrange, successful Manitoba business and to discuss the external happenings that keep the senior team up at night was a gift. We were able to dialogue on a number of potential threats, determine if they were real and determine possible solutions. In essence, we engaged in Scenario Planning as an approach to strategic planning.

Scenario Planning is an approach that is used with other strategic planning models. It is particularly helpful to ensure that the core planning team truly engages in strategic thinking. When focused correctly, strategic issues and goals are identified.

That is a great benefit to any business.

Most literature tells us that Scenario Planning is a five step process. The key is to ensure you take the time to openly identify perceived issues, determine if they are real and decide what to do about them.

Step one is to identify and select several external forces and think about and consider related changes which might influence and impact the business. This might include a change in regulations, demographic changes, education alterations, economic activity, etc. An environment scan of media – both traditional and new – for key headlines often suggests potential changes that might impact the business. This type of business intelligence can be automated in technology savvy workplaces.

Step two is to remember that for each change in a force there is an impact. In this case, discuss three different impact scenarios for the future business. Consider including 1) best case, 2) worst case and 3) reasonable case scenarios that might arise within the business from the resulting change. Reviewing the worst case scenario often provokes strong motivation to change the business.

Step three is to consider what the business might do. This leads to developing potential strategies for each of the three scenarios to respond to change.

Step four involves the core team indentifying common strategies that must be addressed to respond to possible external changes. This is the moment of truth as the team starts to see opportunities to deal with external forces that will impact the business.

Step five is to select the external changes most likely to affect the business. Traditionally this is done over a 3 to 5 year business planning horizon. However, depending what business you are in and the way technology works, planning horizons are collapsing to 18-36 months. You need to consider the planning horizon that makes sense to your business and identify reasonable strategies that can be leveraged to deal with rapid change.

If used correctly, scenario-based planning is extremely powerful. It allows for a guided dialogue on realistic events that can have a dramatic impact on a business and its people. All businesses need to keep a keen eye on the horizon and consider the events, positive or negative, that can impact their future. The key is working pre-emptively to ensure approaches are in place to deal with uncontrollable issues that may arise.

Don’t forget to leave your comments below.

Project Success is in the Eye of the Beholder

Written by Kiron Bondale on March 12, 2014. Posted in Articles. 3 Comments on Project Success is in the Eye of the Beholder

bondale March12 A common method of evaluating the performance of a project team is to determine if they met approved scope, time and cost baselines. While PMI and other project management advocates have spent significant effort in elevating the perspective of project managers to influence achieving expected business outcomes, most still consider themselves successful if they have met the triple constraint.

Assessing this this would seem to be a relatively straightforward exercise at the end of each project – if the project’s customer has confirmed that approved scope has been delivered, and actual cost and end dates matched the approved budget and timelines, you’d expect that teams should be able to pat themselves on the back for delivering one more successful project.

In a perfect world, projects never experience any changes and there would only ever be one set of baselines. There would be little doubt that delivering originally defined scope on time and on budget could legitimately be considered success.

However, as we know, change is pretty much the only thing we can count on when managing projects.

Some changes are driven by our customers – as their knowledge of what they want evolves to meet their expected outcomes, they will come forward with requests for scope change which after due analysis and approval would usually result in the creation of new cost and time baselines. In such cases, if the project team has successfully been able to deliver to these revised baselines, then they should be happy.

Where things get murky is when changes to project cost or time baselines are not caused by scope changes.

Sometimes, the ability to avoid these impacts is not within the direct control of the project team. Common examples of this include:

Resource reductions resulting from decisions to lower the priority of a project.
Budget reductions due to fiscal tightening measures on the part of the project sponsor.
Schedule changes resulting from cross-project re-prioritization.

In such cases, it would not be fair to hold the project team accountable to their original baselines as no amount of good planning or risk management could have prevented these impacts. Formal project change control should be executed and new baselines established. Then, if the delivery team is able to achieve the new baselines, all should be well.

But how do we handle the scenario of being over budget, behind schedule, or delivering less scope than expected as a result of inadequate planning, underestimation, optimistic resourcing or ineffective risk management. Such cases should be treated as variances and if they cannot be resolved by the end of the project, then the project team should be held accountable for a miss.

However, when we are managing projects for internal partners, you rarely find strict adherence to this “by the book” approach.

Common reasons for not doing so include:

Projects which fall behind schedule or run over budget usually do so fairly early in their lifetime, and if the expected remaining duration of the project is long, there is a strong desire to avoid unnecessarily punishing the project manager and their team members by showing their project as being “red” for a prolonged period of time. The demotivating effects of this negative reporting are likely to impact team morale and productivity hence further hurting the project.
As the project manager is usually reporting up into a senior delivery executive, there is motivation on the part of that executive to demonstrate that their department is meeting expectations.
Schedule delays usually cause increased resource utilization, and if the company’s funding authorization policies dictate that incremental costs have to be managed through formal project change control, then the only way to get the project team to work beyond approved funding limits is to approve a change request.

So what ends up happening is that the internal sponsor is “encouraged” to approve a project change request which formally incorporates the unavoidable variances within a new set of baselines. While paying more or waiting longer to receive expected scope is bad enough, in some cases, if the funding increases cannot be approved or if project deadlines cannot be pushed back, the only option left might be to reduce scope. Then, if the project team claims that they successfully delivered the project based on the revised baselines, the internal sponsor is unlikely to wholeheartedly agree.

If it is not feasible or reasonable to hold project teams accountable for realizing expected business outcomes and if meeting final baselines hides approved variances, perhaps the better compromise is to treat those projects which were delivered to original baselines plus approved externally-driven changes as successful.

To plagiarize Benjamin Disraeli: ‘There are three types of lies – lies, damn lies, and project success.’

Don’t forget to leave your comments below.