Preventing Scope Creeping

While discussing scope creep during class I began thinking of a project that I was part of where the vary issue became the downfall of a relationship with one of our biggest clients. My company, an investment operations outsourcer agreed to take on a process (and the tool that went with it) in order to win a client relationship. I wanted to better understand what could have been done in order to prevent the disaster that we ended up with. I began researching scope creeping and I found a blog ( that contains what seems to be an easy 5 step process. I decided to go through each of the steps and see if we would have acted differently regarding each step.

Step 1 is to understand the outcome. This seems like an area we just dropped the ball on. For this process we understood what the client wanted as a result, but we didn’t understand why. If we understood the reason they were in need of this process we could have been able to offer up other solutions that would have been a much easier deliverable. At the time we already had a product that was comparable to what we took on from the client and would only require implementation to the platform rather than development of and integration of the client’s tool.

Step 2 is to be critical of your client’s Ideas. This is another area we did not perform well on. We simply took the client documentation of their process and began emulating it. What we should have done was to analyze their process and determine if that best fits our model. From there should have discussed changes to the process. Our clients come to us because we have standard procedure across that board that work well, in this case we lost sight of that.

Step 3 is to clearly define the scope of the project. For our scenario I think we did a good job of outlining what the scope of the project was. The issue is that the client decided to change the scope. The amendment to the scope was the lingering factor of whether we would continue the relationship or not. Having already invested significant resources to the relationship, we didn’t have a choice and agreed to change the scope. Because of the change we had to integrate manual procedures and caused errors and financial losses that ended up straining the relationship with the client.

Step 4 is to Price the project correctly. This would seem to be a good deterrent for scope creep, but in this case the project was one of those “Price in no object” situations. The client required the change due to regulatory requirements for expanding business.

Step 5 is to get it in writing. As part of projects, the client is required to fill out a project initiation form that details what they are for in terms of deliverables. This form would capture the scope of the projects. I think we could improve upon the form by addressing scope creep specifically in the document stating that we would require any changes in scope once the coding is complete to be addressed as a new project initiation form.

I think the 5 steps are helpful in addressing and mitigating scope creep risks. I think by using these steps in most cases we can avoid scope creeping all together, but it’s not the case in all situations. As we saw in step 3, even if your following certain rules scope creeping can’t always be prevented.

The Frustrations of Working within a Matrix Organization

The matrix organization is a relatively new concept when it comes to an organizations structure.  A matrix organization is a hybrid between a project management structure and a functional hierarchy (Larson & Gray 74).  The exhibit below shows different types of matrix organizations.

As a defense contractor, my company is most closely aligned with the project matrix (also known as a strong matrix).  Whereas I understand the benefits of the matrix organization (promotes higher efficiency, creates cross-functional relationships, etc.), I find that many of my daily frustrations stem from this type of organization.  I often feel that I have too many bosses, and sometimes they seem to be blissfully unaware that I have responsibilities on other projects and/or for other managers.  Communication is another issue because I either receive the same e-mail from five different people, or I do not get communicated with at all.  There have been many instances where a coworker has received a piece of vital information from one of their project managers, and I hear nothing because my project manager thinks the information should have come from my finance manager.

So now that I have identified all these challenges, here are some suggestions to follow in order for the matrix organization to work successfully:

Define your role and each manager’s role

Talk with the functional manager about what is expected from you and what he/she thinks your role is within a project team.  Additionally, each project manager has different expectations, so speak with him/her at the beginning of the project.  An open dialogue about what is expected from you as a team member and him/her as the manager can be very beneficial.  Work out any ambiguous areas right away.


Communication is key!  Keep multiple managers in the loop about your work load and your deadlines either in a formal status report or informally during staff meetings.  Ask that you be included on the distribution list for vital communications.  If any issues arise, communicate them as soon as possible.  Project managers should also make sure that they have a regular form of communication with each of their team members.

Embrace diversity

Lastly, take advantage of the matrix organization.  It provides employees with the opportunity to make connections with other employees in different functional organizations.  Project managers should encourage an open team atmosphere.  As a team member you can learn about different areas in the company that interest you as well.  Who knows, you may find a new area of interest!


What type of organization does your company utilize?  Do you think it is the proper organization for how your company operates?

What are some of your personal experiences (good or bad) with the matrix structure?



Larson, E. W., & Gray, C. F. (2014). Project Management: The Managerial Process (6th ed.). New York, NY: McGraw-Hill Education.

Perceptions of Time in Project Management

I recently read an article on the PMI website titled “Adjusting to Team Time Warps“. The article addresses the issue of how people view time differently when managing their projects. This would be a particularly interesting issue to look at during the planning portion of project management process, when analyzing and formulating strategies to reach a given objective. Understanding each individual’s perspective on time could help prevent future conflict. It may also help anticipate the different needs of each party involved in the project management process.

So how do people “see time”? We are able to see from a cultural prospective, how each culture interprets time differently. For example, Western Europeans are focused on the future, and believe the present is just a means of ensuring a good future. Americans are very focused on the present, seeking immediate gains or results. However, Southern Europe, Asia, and Africa focus on the past, and as a result, feel the future is uncertain. These different perspectives of time can be important to acknowledge when managing a global project. In order to ensure everyone is on the same page, the project manager may need to emphasize important time related goals or deadlines to certain people in a different way. It is also important to be cognizant and respectful of the way other cultures think and feel about time. Someone from Asia may not feel the same sense of urgency of finishing the project on time, as someone from America might

However, I believe this idea of having different perceptions of time can be applied to all projects, even if it doesn’t appear you are dealing with a variety of cultures. Someone with a present focus may be more likely to take actions leading to immediate gratification, versus making decisions toward the betterment of the long term project. A good project manager should be able to identify individuals with this mentality, and coach them toward the desired outcome. This may also help to alleviate any personality conflicts that might have occurred among the team, because of they are stuck in this “time warp”.

I currently work for an industrial supply chain. We have multiple departments who handle the same customer order on any given day. I see issues occurring in different departments as a result of conflicting perceptions of time. For example, the Returns department handles customer orders that were sent out with incorrect material or had quantity discrepancies. This department has a focus on the past. They believe we should be taking our time to ensure we are completing orders correctly, and packing the material in a way that is appealing to the customer and prevents damage to the material. Doing so would eliminate many of the problems they face on a day to day basis. This conflicts with the shipping department who have a future focus on time. Shipping believes in finishing orders and loading the trucks for delivery as fast as possible to ensure each customer gets their shipment on time. Both of these views conflict with the department in charge of picking the orders, because they are focused on getting the material off the shelves and into shipping. They are not concerned with the process before the material arrive on the shelf, or what happens after it has been picked. The order pickers have a present focus.

Has anyone ever been a part of a team where perceptions of time have impacted a project’s processes or outcomes? How did you deal with any problems that may have come up?

Handling Negative Feedbacks

We all have received discouraging reviews or feedback in our lives that we wished we would have handled better or used as an opportunity to learn from it.  Feedback whether positive or negative are an important part of continuous improvement process that we all go through in our careers.  The way we handle these negative feedback defines how we function in a team environment and how we are seen by the upper management.

Everyone has their own way of handling constructive feedback, but there are some basic methods that should be employed to learn from discouraging comments from your teammates or management.

Identify the Review:  There are two types of reviews, constructive and destructive.  Destructive reviews are not usually meant to encourage you to work hard or improve yourself but to put you down and they are usually personal.  They should be ignored.  Constructive reviews may seem harsh based on how it is delivered but it still has value and will help improve your performance and image.

Identify the Source:  Not all the constructive comments may help you improve professionally.  You need to identify who is providing the review and determine whether the person or the team members are the right people to provide the comments.  Are these the people that you respect and have your best interest in mind?

Be Brave, Listen & Clarify:   As difficult as it may be for you to listen to comments about your short falling or lack of performance from the people that you respect, it is important for you understand your weaknesses.  You must keep your emotions in check in order for people to give you honest feedback. Listen carefully to understand how your performance is seen by others and ask for clarification when necessary.

Learn & Grow:  Use the feedback received as an opportunity to enhance your performance and skills. Furthermore, do not wait to get feedback from your teammates or management until annual performance review, ask for continuous feedback.  This way you will not have to wait until end of the year to find out how your work is perceived by your peers.

Overall, there many different things that may affect your performance, whether its schedule, project complexity, or something personal and not everyone involved in providing the feedback will be aware of all your situations.  However, constructive feedback are still great way of identifying your weaknesses and determining how you are seen in an organization, which will critical in your professional career.

Have you ever had a negative review given to you by your teammates or management?  How did you handle it?  Do you think the review was fair?  What did you learn and improve from it?





Project Management in the Construction Industry

One of the topics we have been discussing in class is scopes of work. When writing subcontract agreements in the construction industry, writing the various scopes of work for each subcontractor is a critically important task. In general, each subcontract would include what is known as the “boilerplate” agreement, standard contract language that stays the same on every project. Then the scope of work section of the contract agreement is written, specific to the tasks you expect that subcontractor to perform during execution of that individual project. Writing the scope of work effectively tasks a lot of skill and communication, and I’m sure it is the same in many other industries. It is a balance between being too specific and too general. If you write the scope of work too specifically, and you make a mistake or omit an item, you as the general contractor bear the responsibility (and costs associated with it). If you make the scope of work too general, the subcontractor will add cost to his or her price for things you may not want him or her to do, things you may have already purchased from another subcontractor. Creating well-written scopes of work is one of the most important responsibilities of a project manager in the construction industry. Do any of you have experience writing scopes of work in industries other than construction? Do you follow any specific strategies when writing them?

There are numerous tools available to assist a project manager with organizing and managing the numerous tasks required on a large construction project. One important tool that we use is the project plan. Developing a project plan like we discussed in class is not only a good idea but a requirement at my firm. It requires a tremendous amount of work to produce, but it can be an invaluable tool used throughout the life of the project. Some of the items the project manager must determine and then include in our project plans are the project schedule, monthly gross billing projections, general  conditions budgets, project risk analysis, contingency budget, profit analysis, staffing requirements, and many other items. Clearly it takes a lot of effort to create the project plan during the start-up of a project, but it helps organize and present the critical project information in a format that is consistent and comparable throughout the firm. Is creating a similar project plan document used in your firm to manage projects? If so, have you found it useful and worth the effort to create?

While discussing project management in the construction industry, I also wanted to share an exciting new tool that is currently revolutionizing the way commercial construction projects are managed. The tool is called Building Information Modeling, commonly referred to as BIM. The benefits of BIM are limitless and have changed much of the way construction projects are managed. BIM is essentially a computer program that creates a 3D model of the construction documents (blueprints and specifications). Combined with cloud technology, the benefits of BIM modeling are tremendous. Since the tool is not applicable to all industries, I have attached a link to a short video from Devenney Group regarding BIM if you are interested in learning more.

Personalities in Project Management and Building Teams

A project manager (PM) has a challenging enough task to coordinate deadlines, resources, and workflows. Yet with many different personalities and expertise coming together on a project the PM also has a responsibility to build up a team. This soft side of project management, fostering internal team relationships, is crucial to a project’s success.

For a quick introduction to team conflicts at work take a look at this video by Jennifer Whitt, Director of

Reflecting on the short time (3 months) I spent covering as a PM for a coworker, I found the soft side of project management to be the hardest. You can have an approved schedule and project plan but if conflicts occur within your team it immediately puts the project at risk. I encountered this recently coming into a team with members that already knew each other. Many of these members were accustomed to working a certain way and challenged changes I made to the plan. Others welcomed my support and guidance. However balancing these two extremes became stressful as I worked to transition the project back to my coworker.

In our first class we discussed the Technical and Sociocultural sides of project management (Larson & Gray, p. 17). While this framework is helpful in understanding the combination of hard and soft skills necessary to lead projects, I wanted to seek out additional information on how PMs handle personalities within a team. I discovered an abundance of study on high performance teams (Lake Superior Chapter ASTD, 2014). I also found some workshops focused specifically on this topic, along with other studies on personality assessments and team stages such as Tuckerman’s forming and storming model.

One theory that seemed most relevant to my conflicts at work is Elias H. Porter’s relationship awareness (Anderson, 2010). Porter developed an assessment called Strength Deployment Inventory (SDI) to explore relationships from the following four premises:

  • Behavior is driven by motivation
  • Motivation changes in conflict
  • Personal weaknesses are overdone strengths
  • Personal filters influence perception

Using Porter’s theory to reflect on my own experience I realized that I was so focused on meeting pre-existing deadlines and working within the norms, that I neglected to build a better relationship with the team. Coming into a team as a new member I did not take a step back to reflect on my own motivation. In addition, my perceptions were influencing my reactions to other team members. I often felt like an outsider trying to manage the big picture when other team members had more information being on the project for over a year.

Overall I’ve found that understanding your own personality and reaction to others is key in leading a team. If you become wrapped up in the day-to-day work and forget to handle the human side of your team, listening to and motivating others, you are not doing the project justice.

Additional questions to consider:

What tactics have you found helpful in building up project teams?

Are there any project failures you attribute directly to internal team conflicts? Do you think it was possible to overcome them or doomed from the start?

Are workshops on high performance teams worthwhile?

Would you use the SDI ( for a project team at work?



Larson, E. W., & Gray, C. F. (2014). Project Management: The Managerial Process (6th ed.). New York, NY: McGraw-Hill Education.

Lake Superior Chapter ASTD. (2014). Building High Performing Teams Certification Workshop. Retrieved from

Anderson, B. (2010). Project Leadership and the Art of Managing Relationships. T+D magazine, 58-63. Retrieved from

Whitt, J. [projectmanagervideos]. (2013, September 16). How to Manage Team Conflict [Video file]. Retrieved from

Project Managers and Business Analysts Working Together

PMI has created a new certification for Business Analysts.  I think this reflects a continuing interest and growth in the profession of business analysis – creating the right requirements to maximize value and limit change in new product development.  Of course, this is beneficial to the project manager and the project as a whole.

A few months ago my company hired a business analyst in an existing group.  The addition of this BA to the software team was advocated by the director of software project management and reports directly to that person.  When an organization introduces a new position or function into a team where people know their roles or, at least, know which functions they typically fulfill, there is opportunity for both increased productivity and confusion.  This has prompted me to think about the responsibilities o the project manager (PM) and the business analyst (BA).  Some view the PM and BA as two sides of the same coin–complementary, but mutually exclusive.

According to the Project Manager’s Body of Knowledge (PMBOK) and the Business Analyst Body of Knowledge (BABOK), the roles are defined as follows:

  • The PM manages the project.  “Project management is the application of knowledge, skills, tools, and techniques to provide activities to meet the project requirements.”
  • The BA identifies the business needs.  “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

In many projects there will be opportunity for overlap that can cause conflict.  Those areas include:

  • Scope Management. A conflict can arise when the project schedule, owned by the PM is impacted by the inclusion of new requirements from the BA who owns the solution scope.
  • Communication Management. Conflicts can arise if either the PM or BA is aware of project needs that the other is not.  The PM should not make unilateral decisions.  Likewise, the BA should not make commitments without consulting with the PM.
  • Risk management. All project and product risks must be appropriately identified, and strategies to avoid those risks developed.
  • Requirements Management. The PMBOK includes collecting requirements.  This is, of course, a BA function and can be a cause for confusion between the PM and BA if not well aligned.

Recommendations to encourage a successful working relationship between the PM and BA (Enfocus Solutions):

  • Clear, documented, and mutually agreed roles and responsibilities activities.
  • Plan of when BA deliverables that will be produced that is incorporated into the overall project management plan.
  • Implement mechanisms to promote open communication.
  • Openly discuss the reporting relationship.
  • Both roles should actively engage the business sponsor.
  • Build a partnership based on mutual trust and respect.
  • Work through conflicts with clear and frequent communications.


What is the relationship like between the PMs and BAs in your companies?

Are the responsibilities of these roles clearly defined in your companies?  Are those role definitions always respected?

Has anyone ever served as both PM and BA?

New Direction for a Project

Pretty much all companies and organizations have at least 1 project going on to help their company in either the long or short run. Some projects become wildly successful, but many fail, or become a completely different project than expected. My question is though when does it become that time to take a project in a new direction to prevent it from failing?

The company I currently work for is developing a new system that is going to run everything from operations, accounting, reporting, etc., an ERP (Enterprise Resource Planning System) system basically. They decided this was needed as one half of the organization was acquired back in 2006 and the two sides of the same company have been operating on two different systems even after the acquisition. The idea is to streamline the two sides of the company all under one umbrella to help keep data, and operations under one roof. I could go into great detail, but basically the goal is to save everyone a lot of time, emails, and money. The project though has been dragging on for two years now, they recently have started testing the new system and there is a number of glitches and unexpected problems, and probably the most hampering is the system itself is far too slow with a lot of lag time. My company in large part has developed and begun to implement this project by themselves, and I can’t help but wonder if maybe it is time to get some help.

Many companies with a project of this scale would enlist the help of consultants that have experience running projects and implementing systems of this scale. I personally feel this would be the way to go for the company to help get this project back on track, as the roll out is long overdue. The questions I have though are is it too late? Specifically that since this project was taken on by the companies IT department it would take a good deal of time and of course money to bring in outside consultants and get them up to speed, if a consulting firm was working on the project from the ground up there wouldn’t be this question. My second question is should the project be scrapped? Again lots of money have been dumped into the project, which to this point has been largely unsuccessful. Is it worth it to continue to dump money into developing the system and get it to work, or would it be better to work with an outside firm such as Oracle to develop a new system?

In class we have learned that it is common practice for a project to change overtime, and the strategy of the company may change as well. Also that when a project is focused on solving a problem of relatively low priority to the company it can become a failure. I feel my company has failed in these two focuses, especially the second one. It seems the focus of the company has been focused on getting this new system rolled out, and in the mean time no one is working to improve the current system which has greatly hampered current operations. Also while this new system will save us some money in the long run, in the short run it seems there are a variety of focuses the company could take that would save a lot of money in a very short time frame, but they are all on the back burner.

I guess my question to you the reader is has your company ever had a project that needed a new direction? Also where you able to determine the timing when you knew the project needed the new direction…aka where you able to get the project on a new track before it officially became a failed project?

Organizational Conflict

In the last MGT598 class, we discussed the various advantages and disadvantages of the different types of organizational structures and worked through related issues in the Moss and McAdams case study.  The company for which I work shifted from a functional hierarchy to a hybrid matrix within the last year, which concluded in a mixed reporting structure throughout the company.  Some teams remained grouped by functionality, some were grouped by client or project, and more still were subject to both.


I am a manager for a functional group that spans many of the clients, so I found myself facing a lot of the same issues from the case study such as stated in the textbook:

1)      Dysfunctional conflict – client managers would argue over whose work was the most difficult to obtain the best resource

2)      Limited technological expertise – when resources have to be assigned to each client instead of from a pool it becomes more difficult to balance varying levels of expertise

3)      Poor integration – finding resources to backup or replace those on vacation or sick leave is harder due to the lack of flexibility

In many instances I found that I had inherited the worst of both worlds without any of the advantages, combined with lower headcount following the recession there has not been any recruiting effort to replace or train to meet the changing needs of the clients.

Where should I start to address conflicts with the new reporting structure?

Previously I had established a backup structure which could be easily adjusted as all resources were in a pool under my control.  With the new structure, resources would have to be assigned on a dedicated basis.  I first performed interviews with the resources to create a job analysis document – hours, difficulty, and flexibility for the workload for each client.  I then created a skills document to reflect the levels of talent and experience and produced a skill gap analysis to present to the client managers.


Having the additional input of the managers was important, as there were many interpersonal factors I had not considered such as past grievances and other incompatibilities.  But above all it provided me substantial proof to get a consensus that an additional resource was needed to compensate for the loss of flexibility available for the change.  The documents I created allowed me to translate the skills and requirements into a requisition for a new hire and I was able to meet the clients’ needs.

But where were the organizational considerations?

It was clear that the decision to change the organizational structure was driven by a desire for control from the higher-ups, tired of splitting resources with other departments.  They sold the initiative on the basis that it provided better accountability and cost attribution, yet in reality they were scavenging the smaller clients to feed the needs of those they felt were more important.   The decision to make the change was made from the top down on an inconsistent basis, hinting at favoritism and lack of communication that would have been easily avoided by speaking directly with all team leaders.

In many ways I felt sympathy for Palmer from the case study, being a new manager and struggling against the demands of others.  Yet I was also in a position similar to Sands, having to appease multiple parties at the same time with the limited resources available.  I found the difference between us being my readiness to take action early on and willingness to commit – while compromises must be made, not everything must be compromised.

Recovery from failed projects are key

Do you believe in the evaluation process to determine critical success factors in the WBS or Network Flow of a project?  This can be a key decision tree tool for reducing the need for number of procedures associated with a work stream.  In 2001, we were implementing a project that required 250 manual steps coordinated between 3 resources in an effort to provide a technology transition.  Because of the complexity of these steps, we ended up failing in our first migration.  From that point forward, we had to crash the process in order to provide a timeframe that could accommodate faster return time.  CSF was used to commit to automation and precedence screening in an effort to reduce singular steps and move more so toward parallelism.  The objective was to reduce the number of process steps and resources by identifying CSF in the overall process, defining them as key stages that cannot change and crashing any activity that proceeded it with an eye for dependencies.  Without this learning, we would not have been able to reduce the time to migrate and achieve a 3 hour cut over vs. 10 hours.