Skip to main content

Tag: Change Management

From the Sponsor’s Desk – A Moment of Truth

Written by Drew Davison on . Posted in Articles. 6 Comments on From the Sponsor’s Desk – A Moment of Truth

In my last post, The Four Pillars of Successful Change Management, we witnessed the repercussions a retailer experienced when it decided to move its administrative staff from the downtown headquarters to a suburban setting to provide more retail space and reduce costs. Unfortunately, management failed to include three of the four change pillars in the cost/benefit analysis. They reaped the consequences.

In this post, we’ll look at a chance personal encounter (I call it a moment of truth) that changed the lives of two people for the better. The post isn’t about a project, or a major change. It’s about how individuals react when faced with change. As targets of a change, most often we find out as much as we can, collaborate with colleagues who are similarly affected, revise our practices accordingly and get on with our lives. However, in some situations, for any number of reasons, we ignore the change or fight against it and often suffer for our ignorance or intransigence. Sometimes, as in this case, all we need to move forward is the help and support from another person, to offer a different frame of reference for our consideration.

Thanks to M.D. for the details on this story.

The Situation

A manager at a wholesale business products company located in the mid-town of a large city was heading out for lunch this particular day. The area where the company was located had declined somewhat over the last decade and was now populated with charities and services catering to the down and out. Pan handlers were often seen sleeping, begging or haranguing passers-by.

As the manager headed down the stairs from his office building and onto the sidewalk, an individual sitting on the sidewalk (let’s call him the sidewalk guy, SG for short) reached out with his foot, tapped the manager on the ankle and asked him for a dollar for a coffee. That tap on the ankle caused the manager to stumble so he wasn’t feeling very charitable towards SG. He told him to get a job and walked past.

But then the manager paused. SG was young, late teens perhaps. What a waste. If the manager gave him money, he’d probably use it for booze or drugs. He might have some psychological or emotional problems. What could have caused this young man to be in this sorry situation? The manager turned around and approached SG. He told the SG he couldn’t give him any money but he’d be willing to buy him lunch. SG accepted the offer.

The Goal

It seems neither the manager nor SG had any specific goals in mind. The manager’s reaction was driven mostly by his values and his belief in a sharing, civil society. SG motives were perhaps a little simpler. He was being offered a free meal and he was hungry. Neither of them had any expectations beyond having lunch.

The Project (Lunch)

After SG accepted the lunch invitation, they walked side by side for a couple of blocks to a local burger place, entered and ordered burgers, fries and soft drinks. They took their trays to a vacant table for two, sat down and proceeded to eat. A couple of minutes in, SG said “Thanks man.” They started chatting.

The manager asked SG how he managed to get himself into this situation. SG retorted that the manager wouldn’t understand. From SG’s perspective, the manager had a good job, nice clothes, money to spend. The manager said “Try me”. So SG went into his life’s story. He partied too much, didn’t do well at school, wasn’t great at sports and didn’t have a lot of friends. The ones he did have liked to party too. He dropped out of high school in grade eleven, didn’t try very hard to get a job and just hung out. He stole from his parents to buy cigarettes, dope and alcohol.

Apparently SG’s parents tried everything they could think of to help him turn his life around but according to SG they were just meddling in his affairs. Finally, his parents gave him an ultimatum: clean up his act and go back to school or get a job. When he didn’t do either, they set a one week deadline – clean up or leave. Of course SG thought they were just bluffing. They wouldn’t kick him out. Unfortunately for SG, they weren’t bluffing. The week came and went with no change in SG’s behaviour so they helped him pack, gave him $100, wished him luck and showed him the door.

He’d been on the street ever since, more than six months. During that time, he’d stayed with friends until he’d outlived his welcome. He’d used up his cash long ago so pan handled on the street to pay his way. He slept in alleyways, in parks, in the local homeless shelter. He’d been attacked by thugs, had a tooth broken, visited the emergency department a couple of times. SG finished his story by stating again that the manager wouldn’t understand.

The manager paused to finish his meal and then told SG his story. The stories were eerily similar. The manager had done too much partying, messed up in high school and dropped out. Eventually he had been asked to leave his parents’ house. The key difference in the stories – the manager had managed to get a job. It was a low level job stocking shelves but it gave him the money he needed to support himself, pay his rent and regain his self-esteem.

When the manager and SG had finished their lunches, they exited the restaurant, shook hands and wished each other well. The manager gave SG a little pep talk and they parted company.

The Results

Over the next several months the manager kept an eye out for SG but he didn’t see him on the street again and eventually forgot about him. Five months after the lunch, the manager was in his office when he received a call from reception on the main floor. A gentleman was asking for him. He didn’t recognize the name. The manager asked the receptionist to show him up.

The receptionist ushered a well-dressed young man into the manager’s office. The manager got up from behind the desk, shook his hand and asked the visitor to sit. The manager asked the young man about the purpose for the meeting. The young man replied “You don’t remember me, do you”.

The young man was SG, transformed. SG told the manager that their discussion over lunch that day got him thinking about the future. He realized that his then current situation offered only misery. Although he didn’t really know how he was going to proceed, he made up his mind that he had to do things differently. He called his parents and asked for their help. He didn’t really know what to expect from them. He had put them through a lot of grief but they agreed to meet. He was welcomed with open arms and a few tears. He told his parents about the lunch and how that had been an awakening for him. SG and his parents chatted about his desires, his options and opportunities.

The bottom line: SG’s parents welcomed him home. He got a job at a local fast food restaurant. He enrolled in school and planned to graduate. His parents hired a tutor to help him improve his learning and study habits. He stayed away from drugs and had only an occasional beer. He reconnected with some old friends, ones that didn’t party to excess, and had a girlfriend, his first. He had become a new SG.

How a Great Leader Helped Change the World

I’m sure you’ve heard of the butterfly effect, where one small change in one place can result in large differences in a later state. That one act by the manager, an invitation to lunch, was the catalyst for SG’s transformation. It had a significant and beneficial impact on his life, and on his parents and friends. We don’t know what ultimately became of the new SG but we do know that his potential for success, enjoyment and influence improved immeasurably because of the manager’s action.

So, what does this all have to do with guiding projects and managing major change? Invariably, there are some folks who are negatively affected and have difficulty making the transition to a new, changed state. Change management disciplines aim to identify the change targets and develop strategies to help them make a successful transition. But still, some folks fall by the wayside. That can negatively influence the success of the change and the lives of those so affected. The manager in our story led by example. He took a chance. He saw an individual struggling. He invited that individual, who he did not know and would not normally have invited, to have lunch with him. In the end, the lunch was a vital opening for SG to change his ways. It also encouraged the manager to continue helping the troubled and down trodden.

So, if you find yourself in a similar situation, don’t hesitate to reach out. Don’t let anyone fall through the cracks. Regardless of whether you’re the sponsor, a change agent, a champion or another target of the change, keep your eyes and ears open and, if necessary, act. Start a dialogue. Listen. Try to help others make the transition to the new state. And, if you feel so inclined, offer to buy them lunch. The project will benefit and the world might be a better place.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.

Pay Heed to the Four Horsemen of the Project Apocalypse!

Written by Kiron Bondale on . Posted in Articles. 4 Comments on Pay Heed to the Four Horsemen of the Project Apocalypse!

The Book of Revelation describes the Four Horsemen of the Apocalypse who, based on a common interpretation, foretell the Last Judgment. Regardless of your religious beliefs or the extent of your theological knowledge, there are lessons which we can learn from these harbingers to avoid project failure.

The rider on the white horse is frequently identified as conquest, evil or, in mainstream pop culture as pestilence or plague. In the project context, a common infectious disease is chronic negativity.

Just like a contagion, it starts with a single dissatisfied team member or stakeholder who disagrees with the direction the project is taking, is disengaged or feels the project is doomed. While it is perfectly natural for folks to voice their concerns or to not always be positive, when this negativity becomes the new normal and nothing is done to manage the situation, other team members or stakeholders may interpret this lack of response as being an implicit validation of such behavior and it can spread. If swift action is not taken, the doom-and-gloom prognostications of Patient Zero can become a self-fulfilling prophecy.

Your role as a project manager is not to stifle others views or emotions but it is to be aware of them, and if you recognize that someone is sucking the energy and life out of the team, it is your responsibility to respond in a timely but professional manner. Often times the individual may not be sufficiently self-aware to know how their behavior is being perceived or how it is affecting others. In such cases an objective, one-on-one discussion may be sufficient to turn things around. These situations can also be a good wakeup call for a project manager – if morale has been neglected, it might be the right time to re-energize the group with some team-building activities or other types of recognition.

Another lesson to be learned from this horseman relates to effective change management. Ignore or marginalize the few who are actively resisting planned changes at your project’s peril. It is very easy for unmanaged change resistance to spread from them to the masses and even to infect those who you felt were the best advocates for the planned changes.

The red horse’s rider is generally interpreted as representing war. With the uncertainty which is baked into the DNA of projects and the high likelihood of team members having differing personalities, values and styles, conflict is to be expected.

Conflict is recognized as being a valuable driver of creativity and innovation so the goal should never be to eliminate it. Unfortunately, weak project managers are uncomfortable managing conflict and find themselves letting prehistoric “fight or flight” emotions drive their responses by either being autocratic and forcing resolution or avoiding conflict in the hopes that it will just go away. In both cases the conflict will fester, furthering the gap between the involved parties and increasing the likelihood of other team members or stakeholders joining the battle.

Escalating conflict impacts team morale, reduces productivity through distraction, and provides highly visible evidence of a project manager’s poor judgment and competency, and can often result in their removal from the project. There is no single panacea for resolving conflict but it is critical that a project manager recognizes it and responds at the right time in the right way.

Famine is how the black horse’s rider is usually identified and an obvious analogy could be drawn to the under-resourcing of projects. Unfortunately, in many cases, a project manager has limited authority over resource commitments, especially when working in functional or matrix organizations.

A different interpretation of the third horseman could be ineffective communication with the team and with stakeholders. Some project managers hoard or act as the gatekeepers on information. In such cases, team members are starved for the knowledge they need to be as productive as possible and velocity suffers.

In other situations, the issue may not directly impact the team, but might relate to how well the project manager is keeping stakeholders apprised of project direction and status. This can translate into dissatisfaction, misalignment and perception becoming reality as these stakeholders begin to fear the worst.

A project manager should not overwhelm recipients with information – situational communication which meets the information processing needs of stakeholders is key. The focus of the project manager should be to reduce distance and latency in information getting to those who need it to get their job done.

Ignorance of these three riders increases the likelihood that your project will encounter the fourth and final horseman who sits astride a pale horse – Death!

Don`t forget to leave your comments below.

What Problems Are Executives Trying To Solve With Agile?

Written by Robert Galen on . Posted in Articles. 6 Comments on What Problems Are Executives Trying To Solve With Agile?

Image Source: Imdb.com

Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.

So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:

Well then… if empowering teams, inspecting and adapting, and handling emerging requirements isn’t the problem execs are trying to solve… what exactly *is* the problem they are trying to solve. Rather than guess, I’ve gotten in the habit of asking them. Most senior leadership teams will say something like this…

    • We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.
    • We are putting poor quality products into market, we think agile can help.
    • We need more transparency into what is going on.
    • We need more visibility into the progress we are really making on the product
    • We need to get products into market faster.
    • We don’t communicate very well, I hear agile can help us fix that.
    • It costs too much to deliver software, we want to use agile as a way to lower the cost to product the product.
    • We have way too much to do and not enough resources to get all the work done.
    • Support work is constantly interrupting new product development

Much less frequently, we’ll hear answers like the following…

    • We are trying to better understand our market and are putting out the wrong products
    • We deliver on time, on cost, and on budget but the product wasn’t successful in market.
    • We are looking for better ways of incorporating customer feedback in real time.
    • We are looking for ways to continuously improve our processes
    • We want to help people be more empowered to make decisions.

It’s not that this second group of answers aren’t important… it’s not that they never come up… it’s just that when they do, they are often secondary concerns. They are derivatives of first order concerns.

I’m actually not surprised that Mike is hearing the first list. Of course that’s what the majority of leaders are looking for. And I’m empathetic that they are searching for solutions to these challenges. When I was leading technology teams, from the late 1980’s thru 2012, I personally experienced all of them in a variety of forms. And frankly, it drove me crazy at times.

But what disappoints me a bit is the impression that they’re looking at “Agile” as a “Silver Bullet” that will address what are complex, organizational and systemic problems. These are problems that no mere framework or methodology will have a chance of resolving on its own. It’s this desire, and I may be overreaching a bit here, for a quick fix that disappoints me.

Why?

Because there are no Silver Bullets or quick fixes to hard problems. And any “fix” will require the engagement of this same leadership because most likely, they are a “part of the problem”.

To be honest, I get just as disappointed when leaders look at bringing in a tool or a consulting team as a panacea that will solve their problems as well. Sure tools can help and outside expertise is often valuable, but again, the leadership team needs to be “in the game” with the transformation and not just by paying the bills or initiating the idea.

Looking a Bit Deeper

Let’s take a few of Mike’s points that he’s hearing and drill into them a bit further…

We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.

Absolutely. I agree. But, how are those “commitments” being made. Are your teams making them as you align them with your roadmaps and customer needs? Or are they simply being told what needs to be done by when by “management”?

You simply can’t force commitment and a simply having a job or receiving a paycheck doesn’t necessarily guarantee it either.

Instead, you want to enable a culture and environment where you support commitment and you support the process for your teams to get there. And part of commitment is acknowledging that things will change and there are no 100% guarantees. You have to be willing to trade things (scope) off as progress and discoveries are made. Remember, these are typically complex systems we are developing, which are notoriously hard to plan and predict exactly.

We are putting poor quality products into market, we think agile can help.

Why are you doing that? What do you mean by poor quality? In my experience, executives are often a factor here as they relentlessly drive the organization towards “more”, the message the team receives is that SPEED & DATES trump QUALITY. Agile will try to help with this, by reemphasizing quality deliverables at a team level. But delivering quality is typically hard work.

As a leader, you’ll need to “step down” and adjust your emphasis to be on quality over speed or dates. This may take a bit of time for your teams to realize the shift in your goals. But you’ll be surprised that when you successfully make this shift, with your teams, that you’ll get better quality and relatively increased speed as well.

We have way too much to do and not enough resources to get all the work done.

So if I get this right, a process model or type of SDLC will fix this how? This is the ultimate in Silver Bullet thinking. And beyond that, as a leader, you can actually do something here to help. You can either hire more people and/or prioritize the work so that the most important things actually align with your capacity. But clicking your heels together and hoping to “work smarter” or “get more done with less”, is never a viable strategy.

Agile, if implemented properly, it will force you to acknowledge the team capacity and ask them for the highest priority work that will fill their capacity. And yes, hold them accountable to deliver to their commitments to done software.

Support work is constantly interrupting new product development.

In many ways, support work is a side effect of our own doing. Clearly software isn’t perfect and has issues or drives usage questions. So support is indeed required. But my experience is that much of the support burden these executives are complaining about is driven because they established a culture where speed to market trumped doing things right and holding the line on product quality. Imagine that?

So when you don’t honor quality and release poor quality code, you get hit with high degrees of support and rework which derail your next release. And we all have heard of those repair cost models that discuss finding bugs by review vs. having your customers find them. It’s a pay me now or pay me later scenario. And most teams really want to deliver high quality code. It’s normally the business pressure and overall culture that forces premature releases.

What problems are executives trying to solve with agile?

All right, I may have rambled a bit too much, so back to the point.

I remember when I took my Certified Scrum Master certification with Ken Schwaber he said something along the following lines towards the end of the course:

People get frustrated with an introduction of Scrum thinking that it’s creating all of their problems. Scrum, or any of the agile methods, doesn’t create anything. But what it does do is show you your problems— often every day.

  • As a leader, it will expose to you organizational issues and other more systemic challenges.
  • As a team member, it will expose the impediments and realities of how well you’re delivering your software.
  • As a project manager, it will expose the faultiness of your planning and estimates, etc.

Then it’s up to you to do something about it. Reflect, examine root cause, and make a change. If you do you’ll improve. If you don’t, Scrum will bring it to your attention again tomorrow. It can be very frustrating—particularly if you’re looking for others to fix things for you.

So instead of creating problems, agility creates an environment where the problems are exposed and almost demand resolution. But not simply “team problems”. It will expose challenges that all levels of the organization need to face and resolve—including the leaders who have been giving Mike this feedback.

Wrapping up

Certainly I’m not dumping all of the responsibility on the leadership folks referenced in Mike’s post. I just want some of it to reside there. I’d much prefer that leaders move from silver bullet thinking to truly partnering with their teams. I’d also like them to take some personal responsibility to learn about the methods and the mindset of agility and to engage with it and their teams.

Additionally, I’d ask them to look at the problems that they identified as more holistic and systemic in nature and equally as much their problems as their teams. And finally, wouldn’t it be great if they rolled up their sleeves, with their teams, and got to work on improving things. And yes of course, as Servant Leaders and not Command-and-Control leaders.

Now is that too much to ask?

Stay agile my friends,
Bob.

Don`t forget to leave your comments below.

Effective Communication: A Challenge to Project Managers

Written by Mei Yuen Foong on . Posted in Articles. 2 Comments on Effective Communication: A Challenge to Project Managers

How often we, as project managers have taken communication lightly when managing a project? Most project managers are generally good communicators but are they communicating effectively? In the recent PMI’s 2013 Pulse of the Profession report, it has revealed that the most crucial success factor in project management is effective communications to all stakeholders. The research also finds that effective communication leads to more successful projects and hence allowing organizations to become high performers.

In the same report, it revealed that not all projects will succeed. On an average, two in five projects do not meet the project’s original goal or intent and one-half of those unsuccessful projects are related to ineffective communications. (See Figure 1)

foongapr21Figure 1. One out of five projects is unsuccessful due to ineffective communications.

Communication is one key element which has to be applied effectively throughout a project’s life cycle from the beginning till the end. Hence, why is it that Project Managers are not communicating effective?

The challenges a Project Manager has may include the following:

Stakeholders

A modest project will tend to have a number of people who need to know its progress and about any issues which crops up during execution. Modern projects nowadays often have an added complication of stakeholders scattered all over the globe. Without a solid communication plan and strategy, it will be impossible to keep everyone up to date and informed.

Related Article: The 5 New Rules of Face-to-Face Communication

In addition to that, different stakeholders may have different expectations and hence the method of communication may vary from one to another and hence a standard communication plan may not be effective.

Team members

A project team is generally quite a diverse group of people. Project teams are usually thrust together to deliver a customized and unique benefit to an organisation. In some projects, team members are put together and have never worked together before. The diversity within a project team which can be cultural, geographical, organisational, functional, age related, level of education and so on is indeed the biggest challenge for a project manager.

Ever Changing Situation

All projects are by nature fluid and ever changing. Hence a project manager has to consider the changes and challenges all the way until the end of the project and ensure that the team and stakeholders are fully up to date with issues and progress so that there will be no nasty surprises for them to discover later on.

Hence, to ensure that effective communication is applied throughout the whole project and to overcome the challenges, a Project Manager should incorporate a communication plan at the planning stage of the project. When making a communication plan, a project manager will have to ask the following questions:

  • What kind of communication is required? (Management Meetings, Team Meetings, Management Reporting, Project Records)
  • Who needs to be communicated with? (stakeholders)
  • How frequent is the communication required? (how often)
  • What needs to be communicated? (reports, meeting minutes, details or summary)

A form of standardised communication plan could be adopted. However to be effective and efficient, a communication plan has to be adaptable and suitable to all stakeholders. As described in A Guide to the Project Management Body of Knowledge (PMBOK®Guide) – Fifth Edition, ‘Effective communication means that the information is provided in the right format, at the right time, to the right audience, and with the right impact. Efficient communication means providing only the information that is needed’ Hence, the project manager has to tailor the communication plan accordingly for each project. The plan should be maintained and updated throughout the project life cycle if there are any changes.

There are numerous tools that a project manager can use to better tailor a communication approach. For example, for stakeholder analysis, a Power/Interest grid could be used where stakeholders are grouped based on their level of authority (‘power’) and their level of concern (‘interest’) regarding the project’s outcome (see Figure 2). Once the analysis is obtained, a project manager can now assess how key stakeholders are likely to react or respond in various situations, in order to plan how to influence them to enhance their support and mitigate potential negative impacts.

FoongApr9 IMG02Figure 2. Power/Interest Grid

Another tool project managers can use to improve communication in regards to problems on the project is by creating a fish bone diagram or Ishikawa Diagram (Figure 3). Each bone is labelled with a problem and then it is broken down further by looking at the causes for each problem. This tool is simple but effective at getting to the real issue quickly.

FoongApr9 IMG03
Figure 3. Fish Bone Diagram / Ishikawa Diagram

Using a RACI chart (Figure 4) can be very helpful too in promoting healthy communication in a team. RACI stands for Responsible, Accountable, Consulted and Informed. The chart ensures that at least one person is in charge of each category, as well as helps others to see their role in assisting the responsible person in getting the job done. This also helps prevent communication that does not need to take place and only interrupts the flow.

FoongApr9 IMG04Figure 4. RACI Chart (R-Responsible, A-Accountable, C-Consulted, I-Informed)

In conclusion, effective communication is indeed important for a successful project and in order to achieve effective communication in a project, communication planning is essential and using tools and putting processes in place to ensure daily effective communication during project execution will overcome the challenges and contribute to a more successful project.

Don’t forget to leave your comments below.

Sources:
PMI’s 2013 Pulse of the Profession
A Guide to the Project Management Body of Knowledge (PMBOK®Guide) – Fifth Edition

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

Written by Ambadapudi Sridhara Murthy on . Posted in Articles. 4 Comments on 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].