Richard Flanagan

  • Richard Flanagan posted a new activity comment 6 months, 1 week ago

    Very well deserved, congratulations Mart.

  • We want to go over your weekly activities a second time to make sure there is no confusion.  Each Wednesday morning, you will find a post with questions about the coming week’s readings and case.  Once you hav […]

  • I think this case is wonderful as an opener for an IT Governance class.  Why?  Because there is no governance at STARS, at least nothing explicit.  If we use my “Right Things, Done Right” mantra, we can il […]

  • Readings

    In your own words, how would you define a control environment?
    Define the three kinds of common controls and give two examples of each from your everyday life.
    What is the role of the board of […]

  • I’m happy to see you are all eager to start but the questions for Week 2 won’t come out until Wednesday.  The questions at the end of each ISACA case are dated and refer to al older version of COBIT so please […]

  • Jason,

    Of course you can. Both Jan and I will contribute things we see and think you should give some thought to. For these non syllabus challenges, readings etc. you are free to respond or not. Our approach is that there is one course with two instructors so everyone is free to interact with either of us.

  • I got some questions on the Stars case in an email and wanted to post them here so that everyone can see them.  Please whenever  you have questions about the class materials, ask them by posting on this site.   […]

    • Could we get some clarification on the assignments?

      Two instructors sharing the same medium is causing confusion. Jan posted a “Challenge” in the Week 01: IT Governance. Is this something Rich’s students participate in?

      For the Week 01: IT Governance, was the reading requirement fulfilled in class and is there still discussion questions that need to be posted and answered?

    • Jason,

      Of course you can. Both Jan and I will contribute things we see and think you should give some thought to. For these non syllabus challenges, readings etc. you are free to respond or not. Our approach is that there is one course with two instructors so everyone is free to interact with either of us.

  • Here is the final exam study guide.

    As we discussed in class, the final exam will be a take-home exam. Here are the rules:

    You will receive the exam via email (at your Temple email address) by noon on F […]

  • Leave your response as a comment on this post by the beginning of class next week as well as your comments on your peer’s responses. Remember, you need to average four posts a week for a B. For these wee […]

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      In one of my previous workplaces, there was a project where digital and TV integration was the foundation on which it was to be based. There was no way the project would have taken off otherwise. Because it was a complicated technological innovation which hadn’t been tried at the organization before, the project was undergoing a lot of uncertainty. My manager, who was the Director of Interactive, created a framework which would keep the social element in the center of everything and the project would be formed around it. The project initially started off with the music team being the crux of everything, because it was a music product. As the project moved along, and was so technology heavy, a lot of responsibilities actually came on the shoulders of my manager. With time, it became more of an Interactive team’s product than the Music team’s. As the dependency was majorly on our team, my manager got command, and was able to leverage that to take charge of the project. In the end, once the project was completed, it became known to be more of Interactive’s innovation than an innovation by the Music team, even though the idea was initiated by them. Through most of the project phases, my manager was the commander-in-chief for the project, and was able to dictate what should and what should not go into it. The gradual shift of power from one team to another was clearly visible.

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      A few years ago I was placed on a project dealing with data mining and data analytics. It was a year long project that was for a product that was not yet officially GA (Generally Available) to the clients as of yet. The product provided the ability for clients to evaluate the care provided based on statistical patient data and how efficient the quality measure sets provided by CMS were. Once the new code was proven out and the team received 2 patent awards for the work done it laid the ground work for providing the parent product’s meaningful use reporting solution and now the population health solution. Prior to meaningful use, and now population health, most financial and personnel resources were focused on the inpatient, ED and ambulatory EHR.

    • I believe waterfall methodology is more susceptible to fail as opposed to Agile. Since, Waterfall approach is a one way route which starts from requirements and flows all the way to the maintenance. So if one team misses a milestone in any stage then it adversely affect the complete project and can lead to failure. These slippages can happen due to multiple reasons such as improper capturing of requirements, lack of enough communication between the teams, and insufficient skills available within the team to deliver the product. On the flip side, even agile methodology can be hit by all these adverse effects but since Agile approach involves various iterations it gives project and team members enough opportunity to align to changing scope, implement proper communication channels, and acquire proper skilled staff. Thus, Agile is less prone to failure as opposed to waterfall approach.

      • I agree with you. Another negative aspect of waterfall methodology is that development cycles tend to be long and there is a higher likelihood that the market demand for the feature has passed by the time it is finished.

      • I also think Waterfall is more likely to fail. As you said, doing the incremental iterations makes it easier to identify any potential problems or changes earlier than going through the sequential steps of Waterfall where problems may not be identified until late in the project.

      • That’s a good point you made about improper capturing of requirements. When I think about waterfall, I think more about the process and the steps and none of those matter if you have gathered the wrong or are lacking in requirements necessary for the project to me successful. This error would not be captured until it was too late having time and resources be wasted.

      • I agree with you. However, I am curious about what the advantages to use waterfall compared to Agile. Since Agile management contains lots of communication and interactions with the team and customers, the project may easily get taken off track if the customer representative is not clear what final outcome that they want. It is also challenging to integrate the opinions and have flexibility in scope of work, time line and budgets. Waterfalls method seems to have less flaw on those points.

      • I am with you on this Rishabh.

    • 1.Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization. Approximately 10 years ago we implemented an electronic time & attendance system (some of you are familiar with Kronos). It is hard to imagine how a 24×7 operation (hospital system) could ever have operated with it! Prior to the electronic system, timesheets were printed with paychecks and were submitted for the next pay period by managers handwriting in the hours worked (or benefit time taken) for each staff member. Oftentimes, managers delegated this task to subordinates or administrative support personnel. With the introduction of the electronic system, a new policy was implemented that allowed only for bona fide managers of record to approve timecards (i.e. elimination of the concept of “timekeeper”). The power shift in this case squarely placed the onus on that manager and many initially balked that they were subjected to such a menial task. Others embraced it as an important responsibility. Managers had always been accountable for their accounting unit and in many cases, labor is the biggest line item. Because of this there was really very little defense on part of those opposed to performing the task.

      • I was working at a hospital when a similar thing happened with Kronos. Prior to Kronos we would punch in and out but the supervisor or manager could authorize a change to the timesheet in case something should happen such as a code situation right at shift change. When the electronic system went in only managers had access to the administrative components of Kronos. They could still authorize changes but they themselves would have to make the change and their signature was automatically stamped on the override process. Upper management never looked highly upon this happening and all mid levels were questions if this behavior occurred often.

      • I am guessing managers had to sign off to ensure employees were not abusing/manipulating the system. Also, I imagine that with the old system there were a lot of errors that ended up being time consuming, and went away with the new system. However, it sounds like with the new system (and having to sign off) managers saved a whole lot of time so it was still an improved situation for them.

      • Even if some managers may see approving timesheets as an admin-like task, I think it’s important and manager’s should be responsible for it. If someone’s pay or hours worked is incorrect, it could turn into a big issue and even be a legal issue. With the electronic system it should be quick and easy to approve the timesheets so I wouldn’t see it is being that time consuming for the managers.

      • Maria-
        I find it interesting when “menial” tasks get assigned to managers and they feel like some of these tasks are below them. However, these tasks are sometimes so important even if they’re small and managers are able to catch problems that administrative support staff would not notice or even know to look for, so in the long run those “menial” tasks” can be underestimated.

      • Hello Maria, nice post and here are my thoughts. Time keeping is more than just getting compensation for work done. The number of hours worked is taken into account to award employees with sick hours and also PTO or paid vacation. Additionally, insurance and unemployment benefits go into this calculation. That is why time reporting and timekeeping is important to organizations as well as the individual. Printed timesheets as part of your pay stub served to keep track of accrued benefits. Kronos or other HCM tools make benefits and pay equitable to every employee. But like you mentioned when managers were directly involved in how much you got paid offered little room for insubordination.

      • Hi Maria – great example of power shift. I am curious to know what the management/ HR did on the change management part of this new system. How long did it take for managers to embrace and accept that the “menial” tasks are actually their responsibility? Change is always hard to implement. In this case change was good because the new system increased efficiency of the time sheet entry process. I have always worked in organizations that had electronic time submission. I used to log in to the intranet, and enter the number of hours I worked on a day basis for the previous two weeks. Once I entered, my supervisor would get a notification to approve my time sheet.

      • Well Maria, this shift in power I think is hierarchical. I know people who sign off coworkers and such in certain jobs. I personally would want my manager to take that responsibility. I would not want my coworkers looking at my time sheet or paystub. I feel that, that practice is a building block for conflict.

    • Stan, was there contention as a result? Although I am in healthcare, I am not exposed t every initiative so I need help understanding if this situation caused a power struggle of sorts. Did inpatient, ED and/or ambulatory EHR embrace this change?

      • Hi Maria. Meaningful use is a requirement driven by the government. Hospitals who want any part of the $17B set aside for it would need to abide by the rulings and any EHR vendor must be certified for inpatient, ED and ambulatory. Population health is the waive of the future for all Healthcare IT companies. If anything, this has created a significant revenue stream and created jobs overall. Whether personnel resources were reallocated it really doesn’t matter since the other EHR components still require support help which is always a significant number of people.

    • This is an interesting story. Did the music team become more of a stakeholder or they just didn’t have the correct resources to implement the idea and were shut out? There are pros and cons to this situation. On one hand your manager of the Interactive team showed they could develop the needed framework and implement it but on the other hand, the idea wasn’t theirs. It may have been a good idea to find a way to work with the music team since they appeared to be the more innovative team but needed help implementing the idea. This would have been similar in the way Wawa works with McLane.

      • Stanley, I would like to believe that knowledge was the key factor in shifting of power in this case. We did end up working with the music team, but the product became more of an Interactive team’s product than the Music team’s. The Music team wanted some kind of interactivity where TV and the digital medium would integrate, but had no idea about how. Our team found a solution to it, scoped out the entire project, and then brought it to life.

    • I agree – in this situation it seems like it made sense for the power to shift to the team with the most knowledge about the project at hand. However, I am someone who likes to see projects through to fruition so I could also understand how the music team could get annoyed with the situation. Do you think the music team was ok with the shift in power? Or, do you think they would have preferred to keep the lead on the project while being coached on the more technological elements?

      • Lauren, I am sure that the music team was not very happy with the shift in power. But sometimes, lack of knowledge does leave one powerless. But just as you said, all the team wanted was the product to be ready to go live, and I think they did get that on time. And I must say they were amazed on how the product actually led to increased viewership in that timeslot. The TV Show ended up becoming the highest rated on the channel. 🙂

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer.

      I think the Waterfall model is more likely to fail than the Agile model. Since the Waterfall model has all the requirements given in the beginning, it may not be successful because the requirements can change during the process. An example of this in the readings was the implementation of the healthcare.gov site. There was disagreement on the requirements, function, scope, and design of the site. Using the Waterfall approach they were unable to go back to modify previous steps. An Agile iterative approach with pilots and beta testing would have helped mitigate some of these issues instead of releasing the site to users all at once. However, it can sometimes be harder to use an Agile model with very large projects since Agile requires a lot of cross-functional coordination. It was stated that large IT projects are more likely to fail than smaller ones with projects over $15 million having a 40% failure rate. The Waterfall model is more likely to involve a larger project whereas Agile is more likely to be smaller iterative projects.

    • I think that for an IT project a waterfall methodology is more likely to fail. I think the Agile’s method’s short development cycles really help it code with changes. It also makes it less susceptible to problems. One the major points of emphasis of the Agile method is on close teamwork, dual coding, face to face meetings, which is one the major ways to fix a problem, Get the right people in the room.

    • My example is similar to Maria’s in that my previous company went from hand written time sheets to an electronic system. With the hand written time sheets they had to be printed out (by me) and often re-printed when staffing changed at the last minute due to someone calling out and someone else getting scheduled to take his/her place. Oftentimes the message would never get to me that there was a shift in staffing so the staff sheet that the supervisor received that day would be wrong. Sometimes I was able to print out a new staff sheet but a lot of the time it was not possible for various reasons. So, we generally ended up crossing out names and writing in new ones. The event supervisor was responsible for signing all employees in and out. The book keeper then had to tally up all the hours and was often incorrect with her calculations, which resulted in incorrect pay stubs and then a lot of headache for her with phone calls and emails. With the new system, employees had to open an app on their phone and then sign in and out with that. The app included a GPS feature so that employees could only sign in and out when they were really at the event location. So, the power shifted to employees and they had to remember to sign in and out themselves instead of seeking out the event supervisor to do it for them.

      • Lauren-
        I could not imagine the headaches that previous system much have caused! It seemed like there was so much opportunity for error and was so inefficient. It seems to make so much sense to put the accountability on the employees themselves and the GPS feature sounds like a very smart solution.

      • I think the GPS feature is a great idea and would resolve any doubts management had about employees “cheating” the system. My group project involves a time management system and it would be interesting to see if the system we are using has that feature since I know it has the mobile app capability.

      • Lauren, that’s a great example of how technology can be used to distribute power within a organization. In a similar situation, I was working at one of the departments at Temple where the students use to login time by themselves at their own excel sheet and then share it with the supervisor. Often times students use to write wrong timings to ensure they get more pay. In order to reduce the power among the students, the supervisor started using a printed login sheet which he kept at his table, so whenever a student use to come in then they entered the time accordingly. This reduced the false time submissions and enabled the supervisor to offer correct pay to students.

      • Hello Lauren, I liked the solution to the timekeeping issue described in your post. Reporting time is always a tricky issue because like you mentioned there are two layers of people approving worked time and time paid. The app removed the layers of bureaucracy where the employee has ownership of the time reported to the system via the app. Thus streamlining the process.

      • Wow Lauren. I have never before heard of employees signing in on their mobile devices with the help of GPS. A great way to shift power, and rightly in the hands of the employees. Did the managers who were in charge of signing in the employees annoyed that they lost that power? Also I wonder if employees could sign in only when they were connected to the Wifi in the organization.

        • The managers were happy to lose the burden of signing employees in and out. However, as can be expected, the electronic system didn’t always work as it was supposed to, which created headaches for managers. Employees could use their own data or wifi to sign in/out but sometimes the app wouldn’t recognize that employees were in the correct location and the app wouldn’t let them sign in/out. In this sort of scenario all employees (as many as 30) would go to the supervisor to complain and revert back to the paper time sheet.

          • That is worse, Lauren. Because the basis of this was location, there were clearly a few loopholes that could have been exploited. The system not functioning as expected, and then the supervisor having to deal with all the stress, having a paper-based time sheet was probably a good idea 🙂 Maybe they could have explored the old and simple idea of swiping in.

      • Hi Lauren – Its funny that you talk about power with the employees. All the companies I worked at had an electronic system to enter the time sheets, and the employees had to fill in their hours. I would argue that employees do not see it that way – like they have the power to fill in their time. I would say its more of a responsibility , the power still lies with their managers.

      • That’s a very nice example Lauren. Using mobile apps with GPS feature for employee sign in is a great way of simplifying the previous process. Keeping track of time sheets manually is a very tedious process. Switching to an electronic system and shifting the power to employees made the process much more efficient.

      • That seems really difficult and annoying to deal with. If vital messages are not being directed properly then many things are on the verge to fail and be dealt with correctly. Today, where technology is just advancing it is hard to bring back old handwritten methods.

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer.
      In my opinion, the waterfall model is more at risk to fail. Once a project begins to run out of time and money, the final phase of testing can get cut short making the results suffer. Also, since software isn’t produced until the end of the project, you cannot be sure where problems arose or makes monitoring difficult without an opportunity to makes changes. There is also huge technical risk since you don’t test your software until the end of the project and it may be too late to make changes. Agile on the other hand has a lower amount of risk since quality improves with the opportunity to test throughout and increased visibility with the option of receiving feedback early to make changes.

    • I agree with your point that waiting to test the system until the end seems problematic. It seems like in a lot of situations one would need to ask “the five whys” to really get to the bottom of a problem. Especially with IT, it seems like it would be particularly difficult to locate the root of a problem in order to be able to address it effectively. On the other hand, I could see the waterfall technique being good for a repeatable process, once it is fairly mastered. In this scenario, someone familiar with the process would be able to easily vet out an issue. I wonder if this is the case for how it is sometimes used!

      • Lauren, I like your idea of using the waterfall method for a repeatable process. A company could use Agile initially to complete the IT project, but then use waterfall for additions. I did something similar when publishing stories online, which involved using Blogger to create the appropriate HTML and then copy that over to our less sophisticated blogging system. We would identify the topic and collect information, write the story, enter it into Blogger, copy the code, paste into our system, publish and then check for errors. Some errors might be that the text did not wrap around an image correctly so I would go into our system, fix it and republish.

    • I think most people, myself included, have said that waterfall is more likely to fail which is probably true in theory. I’ve done a lot of both and I’ve seen both fail. Agile just covers it up better by saying “we’re changing direction” and putting a new requirement in front of it. It’s still a failure regardless. We have to remember that many Waterfall aspects are in Agile but it’s just a matter of semantics. Agile even has a form of it modeled after Waterfall but just with shorter iterations. Companies may say they are entirely Agile but when asked in detail I’ve found that they have features that are developed with Agile but when you look at the plan for the backlog it will resemble Waterfall.

    • I agree there’s definitely the potential for either method to fail. A lot of companies use some sort of hybrid between Waterfall and Agile which as you said is basically smaller iterative versions of the Waterfall method. I’ve heard companies that are hesitant to go 100% Agile because it may not be feasible for certain projects. I think the methodology used should be based on what’s best for the particular project.

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer.

      I think waterfall model has greater risks of failure when compared to Agile methodology. Studies show that in failed software projects that were investigated, over 80% of the time waterfall methodology was recognized to be key factor for failure. The main drawback of waterfall model is that the requirements are gathered only once, at the beginning of the project. It follows a strict sequential chain of phases where in it is very difficult and also costly to go back to a previous stage. In most of the large and complex projects, the requirements are changed throughout the project. Since waterfall model separates each phase, mistakes in one the phases would build up and impact the overall project. Also, the product wouldn’t be available for review until all the phases are completed which makes it difficult to identify deviations from customer requirement. While agile also has chances of failure, it is comparatively less riskier than waterfall model as it provides multiple iterations and working software which could be tested and modified as needed.

      • Hello Sadhana, I agree with your opinion that Waterfall method has more liabilities associated with the lack of flexibility and that the team can only move forward with the process. There is little if any for testing and does not lend itself for iterative coding. I also agree that Agile is less risky and that has to do more with user testing and iterations in coding to accommodate solutions moving forward with the project.

      • Sadhana, good way to explain how AGILE is better than Waterfall. Also to add to it, the problem with many organizations is that they want the project to be delivered “yesterday”. Planning the project better and in advance helps. Also, imagine a project like building a device for Sequencing. The tech is complicated, and the machinery heavy with some even heavier coding. I think it is very difficult to execute such projects with the AGILE methodology. In such case, planning better is the only key.

        • Yeah, I agree with your point. There may be situations where it is not feasible to use Agile methodology. As you mentioned, large and complicated projects cannot be handled with Agile and also Agile requires people with multiple skill sets and who are quick to respond to the changing environment. So, yes, it is crucial to plan ahead and evaluate the risks associated with different approaches.

      • Sadhna, I agree to your point to Agile being superior approach in terms of project failures. Another aspect that is key to waterfall is documentation. Because of the nature of waterfall approach, it becomes highly critical to document or keep records of everything. Any miss in the document would certainly create problems to other teams who would be working on the project on different phases. Thus, might result in project failure.

      • Sadhana, You did a nice job outlining the pitfalls of waterfall. It was this course that first introduced me to these methodologies and as such I am surprised as to the amount of chatter about them. Clearly, Waterfall is more prone to fail based purely on its rigidity. I am amused at the different names and “models” being applied in various situations in support of one method over another. Not being a programmer/coder, i do not embrace the core of the arguments or disagreements. At the end of the day, it is the PM that needs to ensure the project gets done be it rigidly or not. As we have learned, earlier approaches (engineering) were more suited to the rigid approach but as deliverables evolve and become less concrete, it is only natural to apply agility where appropriate.

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer
      IT projects with budgets greater than $15mil have a 40% chance of failing probably because the teams doing the coding are larger and communication among them could be a liability. Using the waterfall method for a huge project will more like to go over budget because it moves slow and there is very little opportunity for iteration. It would be better to break down a $15mil into three smaller projects with well defined project scope(s) and manage the risk of failure that way. This brings the project to Agile, I suppose, which allows room for iterative coding, testing and incorporating changes based on test results back to coding the next steps. To keep pace with a dynamic technology sector and global market

    • Stanley, that’s a nice point that you reflected that even Agile has a form that is based on the Waterfall model and Agile could be considered as doing multiple Waterfall versions. I was just wondering whether the failure is similar or not in the two approaches. So based on your experience would you be able to share differences or similarities where Agile and Waterfall failed in the projects that you worked.

    • Stanley, thanks for your balanced opinion. I have read that Waterfall method is not recommended for web information systems, event driven systems or real time systems. If you try to used WF method for these situations you may increase your chances of failing. You are correct in saying that both methods have the potential to fail but I feel that choosing the best method for your circumstance may reduce the risk of failing.

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      The project that I described last week where we upgraded our tee time reservation system to allow customers to book their own tee times created a power shift within our organization away from management to the customer. Internally the distribution of power remained the same, but externally our autonomy of the operation became more of a cooperative relationship. Prior to this change we as management had the ultimate say in where we placed groups on the course and could strategically place groups to maintain the best pace of play. Afterwards customers could see an open time and place themselves where they wanted (based upon time, playing partner etc.) which may not have been ideal for the operation as a whole. We had to develop new strategies to deal with this power shift to maintain control over our operation and the service we provided to the membership as a whole. Overall the new system made the lives of management and the customers easier, but it did not come without its hiccups along the way.

    • I like the GPS feature, but one problem as it would pertain to our project is that even with GPS features, you would need to determine when your business day starts. What if you have an offsite visit that is more than double the distance of your standard commute? Does that extra time burden fall on the employee and How does the manager reviewing the time sheet know about the meeting, or where it is to make sure the employee’s GPS is where the meeting is?

    • Also, I think a project manager really needs to consider the scope of the project. If you are talking about a project that is designed to take years, it may be better to do a waterfall style project. Agile projects are not usually well suited for long term project.

    • Hi Tom,

      I was wondering, was the system originally intended to be open to the public or was it supposed to be for back-end usage? Was there any testing phase prior to implementing the new system? Finally, how did you end up resolving the difficulties you encountered following your go live, were you able to find a balance between managerial and customer control of scheduling?

    • It seems like a power shift from management to customer is especially tricky because you’re taking out the knowledge component (manager) and don’t know what the results will be within operations. Like you said, managers could previously be strategic with placing players on the course. I wonder if there is a way to set up an algorithm to simulate the thinking process the managers went through with the old system. This way, customers would still have the power of scheduling themselves but the system would ensure efficiency. It would be interesting to see how the system’s decisions would stack up to experienced managers’ decisions.

    • Rogelio, loved the way you gave an example for the $15MN project. It makes sense to break it into smaller parts, or maybe phases, which can be carried out simultaneously. But if these phases are interdependent, then this approach could be a problem. I completely agree that larger the projects, bigger the chance of failure or delays. The AGILE method is any day better than waterfall. But I also believe there are some projects that cannot be executed using the AGILE methodology.

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.
      We redesigned the homepage for the magazine’s website. My group’s online editor and special projects manager took the lead, but looped in the rest of the editors because we would need to post to the site daily. The online editor was known for inflexibility and constant scapegoating if anything went wrong. The special projects manager had the most experience on the team and was well liked by everyone. We set up a meeting with the developer for everyone to bring in design ideas based on research of what worked well on other sites and what worked well on ours (largely using Google Analytics). As expected the web developer vision for the site did not align with the editors’ visions, but we tried to reach a compromise. In doing so, we moved away from the original vision of the online editor, which caused him to grow increasingly perturbed. The special projects manager had been through projects like these before so he understood changes and comprises were inevitable. When we removed the final element of the online editor’s design (a radio button in the search bar), he put a stop to the meeting and berated the team for straying from his vision. The developers met with the magazine’s publisher to explain the changes and why many had to be made for the site to function properly and include enough space for advertisers. The publisher removed the online editor from the project to avoid further conflict and gave control to the special projects manager, who involved the print editors as much as possible. By removing the online editor, the web developers and print editors could interact more often, which helped when there were issues with the website later on. It gave us more exposure to publishing content online. While the developers and editors definitely had different personalities, having regular interaction helped us understand each other and our motivations. Personally, it helped me learn how to fix some (very basic) coding issues myself, which allowed developers to focus on larger projects and not spend time changing the color of a headline in a e-newsletter.

    • 1. Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      The CRM supplier switching and upgrading project in my previous company which manufactures and sells re-manufactured Toner cartridge is a good example that cause a power shift within an organization. Before we utilized the new system, our CRM data was more like purchasing record only. Some detailed information about clients, such as the size of their organization, the service type and equipment they own or ready to buy, was either not documented or recorded in sales person’s notes. As the result, if the company lost a top sales, it was hard for new sales to catch up the client service right away. Additionally, it was also limited for sales managers and data analysis team in marketing apartment to provide extra insights about the clients. On the other hand, the sales who own the big clients have huge bargain power to interfere the marketing and sales strategy since they are the only few sources that get in touch with clients. They tended to hide the information that is beneficial to company but may not be that profitable to them.
      After we successfully introduced the new system to the organization, the power of top sales shift to back to management level. The district sales managers can easily monitor and trace customer visits and deals conducted by each sales representative in daily base. The overall power of whole sales department also spread to finance, marketing, production and HR department. With the detailed data, marketing department is able to predict the overall sales and market trend and provide to production as well as finance departments to set the production budgeting and planning. HR department also uses the correct rate and how detailed about the information that sales person input as one of the measurement for performance evaluation. Even though the company faces resistances from sales department at very beginning, the whole company performed better in profit generating, budgeting, target marketing and HR management after introducing the new system.

    • You bring up a good example in healthcare.gov. It was a large IT project so using the waterfall method made sense, but it also had so many requirements that not being able to backtrack caused problems. How could they have circumvented these problems? More testing before launching the site? What other steps might have helped?

    • Hi Stanley, That’s a good point. And as mentioned by John, different situation require different methods of handling the project. Agile projects also fail due to a variety of reasons such as unwillingness of team members to adapt to Agile methodology, lack of proper communication and coordination, insufficient training etc. Most of the companies try to implement a combination of these two models in order to overcome the potential drawbacks of Agile and Waterfall approaches. I think it’s always useful to look into the scope of the project and choose the model appropriately.

    • Hi Sid – Interesting example. The power shift from the music team to a more technology orientation also reflects that scope can change during the execution of the project. Did this shift create any animosity between the teams? How did the teams react to this change?

    • John, I agree that getting the right people in the room is imperative. Sometimes getting too many people involved slows down progress. When I was working as an editor, we wanted to survey our readers to find out what type of content they liked and didn’t like. We met several times to work on questions and refine the skip logic. Every time we made a change, we had to send to the editor in chief, who would make edits and send back to us, which would lead to us sending to him again and so on. The constant checking in led to us never publishing the survey. If one or two editors had come together, published the survey and given the results to the editor in chief and publisher, it would have been more effective. While this was not an IT project, I can see how this type if checking in could hinder the progress of any project. Having finite steps, like in the waterfall method, allows teams to move on to the next stage.

      Using the Agile method, do you think it is possible that team members could meet too often and slow down the progress of the project?

    • Many of you argued that agile is better than waterfall. I think each method had its own advantages. Waterfall is better suited for long term projects. It is a sequential process where developers move to the next phase only after the current phase is completes. This methodology stresses on keeping record of things. Therefore a project will realize minimal impact in case some if them leave during the project. Waterfall should be used when there is a clear picture of the end product, and when the client cannot change the scope. Agile on the other hand is better suited for projects that are fast paced and whose scope is subject to change. Agile methodology can be thought of as mini waterfalls. It allows client to add features, and give constant feedback.
      Finally I would say that in this age where project scope changes very often, waterfall would more likely fail.

    • Pei Yen, this is a great explanation of the power shift and it reminds me about one of the similar scenario that took place in my previous job at a IT Consulting firm. There was a new client that was being added to the portfolio of the organization where I worked. Since, the account was just shaping up there were lot of issues for the web applications that were in place. The team members were trying to solve incidents based on the initial limited knowledge that they had. However, there was no record keeping for the analysis and the resolutions. This made individuals who were handling the application posses more power and also became a hurdle for new joiners to get a quick understanding for the applications’ issues. In order to overcome the situation, I outlined a trouble shooting document which enabled the team to share their analysis and minimized the power and dependency that they earlier had.

      • Hi Rishabh,

        Good reflection. It is interesting that as the leaders or managers in the organization, we hope to spread the power and we want that the organization will not need to overly reply on specific talents or department. However, when we think about our personal career, we hope to own the information and knowledge that others are hard to get to get more bargaining power. I think my former company did a really good job to reduce the resistance by creating the atmosphere with collaboration and providing the facts for sales representatives that they would be able to gain more by giving away some of their power.

    • The original system was only meant to be used on the back end and had been used that way for years. We had a new company come in that could meet our needs of building a portal and connecting to our multiple courses (which is unique for our club.) There was no real testing phase on our end prior to going live. The biggest issue was inputting rules that govern the actions that a member can take and to make sure that all the members were input as the correct type. Through trial and error we were able to find a good balance of control, which mostly involved further definition of rules and procedures for booking.

      I have never experienced a system that I felt worked particularly well in my experience in the golf industry. If anyone wants to help me develop a program it could be a great business opportunity haha.

    • Hello Colleen:
      Responses in this week’s blog the shift in power results in overall improvement of the organization. It is as if the shift was to deal with people problems that affected everyone’s performance, Do you remember if the online editor was retained after the project was completed?

      Best

    • While working with an IT Consulting firm back in India, I was part of a project where the team provided support and maintenance for the web applications that were in place. As part of our analysis, we had to coordinate with Operations Team to gather information from the servers such as log files, hosting, and application pool details, to name a few. Since the Operations team was with a different vendor it made them possess more power and often it was difficult to gather information quickly. Later, the operations department was handed over to our organization which created a positive impact on the resolution time of the incidents. Due to better relationships and working as one team, completely changed the dynamics of the environment.

      • Was it ever explained why the information was so difficult to gather from the original team holding the data? It seems like they possibly saw your team as a threat so they didn’t want to release the information in a timely manner. Maybe they wanted to cause friction, but its good management saw this and was able to correct it in good time frame.

    • Rogelio, he was moved to a different project and given a six month deadline. When that time came, his managers realized he had done nothing on the project and that was likely true of all of his past projects so he was let go. The actual project I worked on (the updated homepage) was a small part of the change. Removing the online editor streamlined our processes and taught us that we didn’t need to separate print and online.

    • I agree the iterative process producing several prototypes in an agile method is less likely to fail, it allows for more testing and flexible requirements. Larger projects not only typically use waterfall because of the difficulty of coordinating across functions, but they also may fail because of their sheer size. Expectations are higher and the resources and motivation to produce not necessarily on the same level.

    • Hi Colleen,

      I think it could slow down the progress of a project, but I also think that the goal of Agile is not to just have constant meetings. Rather, it’s to make the most of the time you have, specifically, when meetings take place, they are face to face and only include the necessary staff. If done properly, it should only help the project move forward.

    • It’s a very interesting situation, what made the management team opt for a portal that basically surrendered their control over scheduling?

    • Swetha, I agree that there is a time for each method and it depends on the scope of the project. A large project that has a clearly defined objective and experienced staff will work well with the waterfall method, while a smaller scale project that is subject to change would benefit from the Agile method.

    • It’s a customer service industry so having the ability to book online allowed us to better serve the needs of our evolving customer needs. We were also a very lean operation and the time saved working the phones allowed us to concentrate on other operational tasks.

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      Within the past several months, my origination has gone through some financial restraints that has caused restructuring of different departments and teams. There were managers and employees that were let go or sought employment elsewhere and due to this restructuring. Those let were let go were instructed to leave immediately. Those that accepted new employment gave the minimum 2 weeks notice. These abrupt actions caused many vacancies on active projects and opened up opportunities for others seeking high roles still available. One project in particular was for kaleidoscope. The analyst assigned to the project as the PM, left the organization and provided minimal transitioning/cross training of information. The new analyst that completed the project basically took it over without proper handoff. There were two analyst assigned to the project. One analyst was more outspoken and not hands-on while the other was the polar opposite. They both had the same power in completing the tasks and assigning SME to key areas, but not long into the project you could see the power shit into the control of the analyst that was more outspoken. Everyone when to the outspoken analyst for issues, concerns, and updates. The other analyst didn’t complain, but just continued to complete the daily tasks to complete the project on time. When the project was done, the out spoken received many thanks and praises for the hard work while the other didn’t as much.

    • Swetha, this is a good point, they both have their positives and negatives. I think that in many cases a hybrid between the two methodologies would be more effective. You should have to place your project strictly in the box of either waterfall or agile. A spectrum can exist between the two and can be tailored to your specific projects needs.

    • This is a really interesting example of an informal power shift. Although they both initially were granted the same level of power, it seems as though the more outspoken analyst quickly gained the perception of power from those around the project. I wonder is the less outspoken analyst was comfortable with this shift in power or upset with the events that took place. It seems as though he or she put in just as much if not more work, but didn’t not exhibit any leadership capabilities.

    • I agree. The waterfall method does not provide a safety net for decision changes down the project line. You can not easily modify or adjust changes if needed. In order to make the waterfall method work, no changes should be made during the project unless completely workable.

    • I agree John. The agile method provides the flexibility for change if needed. This method is similar to the parallel approach used by MediSys Corp reading. Team members work closely together to complete projects and fix issues along the way as they come to light where as the waterfall method follows a trickle down process.

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer.

      The waterfall methodology is more at risk to fail as changes in requirements are difficult to or cannot be incorporated. Often a client does not know, what they need and don’t know, what possibilities are available with the technology. So waterfall does not handle this well. It is costly or impractical to go back and make changes once a phase of production is complete. Solution designers are not able to foresee problems.
      The waterfall process is linear and sequential so it is easier to understand for less qualified personnel. It is good for simple projects and unchanged requirements.
      Agile methodology is more flexible therefore customers requests are more likely to be met.Changes to requirements can be incorporated at any point of the process, even late in development. It gives opportunity for continuous improvement for live systems. It is highly transparent and builds highly motivated teams as production increase over time.
      Agile is more difficult to understand at least initially. When implemented poorly, Agile can introduce extra inefficiencies in large organizations or can work against long standing organizational processes.

    • Siddhesh
      I have seen this shift of power happen in many walks of life. One person leads and does all the leg work and then someone else takes charge or credit. I am not sure there is a cure for this. I guess shift of power is ok as long as the job gets done. Personally, I feel frustrated when that happens.

    • Thanks for all of your feedback everyone! To answer Swetha’s question about what HR initiatives were put in place to support the change, it was fascinating the amount off initial push back. HR as in many cases is only speaking on behalf of the organization and helping to assist with change. PAyroll is not HR yet the coding is HRIS so we definitely played a role. The message about only managers approving timecards was an organization message that was supported by HR and communicated via training efforts. At the end of the day, it was truly a Finance decision (heavily influenced by HR’s input) to prohibit timekeepers. So when push came to shove, we referred the complaining manager to the Director of Finance. You can imagine, things ended there!

    • In your opinion, which methodology is more at risk to fail: agile or the waterfall model? Why? Refer to the reasons for project failure described in our readings in your answer.

      I would claim the agile model is more at risk to fail because with flexibility comes the risk of expanding beyond a feasible scope and budget more easily. The waterfall model seems more structured and stringent, which causes problems of its own- but if a project is well defined at its onset it seems less at risk to fail than an agile model.

    • I agree. I think the waterfall is suited better for projects that will have a longer time span. It also is better to use when one knows that nothing will really be altered as you state. The agile is kind of the opposite where changing works along with it.

    • Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.

      I have not experienced this, but my brother has. He was working on a campaign doing statistical analysis. As the project progressed, the campaign hired a programmer to revamp the analytical process. My brother’s position was all but eliminated by the new program, as were two other people’s positions. His manager was thus unneeded as well, as his job was to monitor my brother and the rest of the team. The team was disbanded and shifted to a single person, monitoring the program..

    • I think it is because agile is suited for projects whose scope is subject to change is the reason it is more risky. I agree with everyone, that each has its place in certain environments. However, if each were executed properly in the correct environment, I believe the agile model is more risky because the fast pace + scope expansion could lead to a project going way over budget and run out of control.

    • Not testing devices, software or anything of that sort is not good because one does not know how well that process is working. There can be many flaws that will not be fixed unless testing occurs. I agree in this case then that the waterfall model is at a more risk to fail because a handful of problems can occur and many things can go wrong if testing does not happen.

    • When I used to work for E Commerce company for lab supplies, they’ve spent about 50mln. $ for 2 years for ecommerce and SAP ERP software. After the second go life which include the most users the system seem to be very unstable and led to loosing 1/3 of the revenue from North America. Which led of replacement the CEO, CTO and the VP of E commerce, it was a complete change of power for the company. The load test, stress test seems were missed and changed the director of QA as well.

    • I agree both have potential to fail especially since agile incorporates some aspects of waterfall. However, I also think that the waterfall method may be more appropriate for certain project, say something the company has done multiple times and it somewhat familiar with any potential issues at the start. The continuous checking in to gain feedback and revise the system may then be unnecessary.

    • That is such a good point! The agile model allows for a more flexible measurement of outcome success by claiming they had to “change direction.” It depends on how an organization would define their success metrics. If success simply means making something- then maybe the agile model is less risky. But if the metric is to complete the project on time within scope and budget, than I would claim waterfall is less risky.

    • I think the waterfall method would be a greater risk for failure. Not testing before is a big flaw in the model because that can lead to many problems. Change also does not work well with the waterfall model which again can cause problems because change is something that is always occurring and will for any project to move forward.

    • The waterfall is more risky because you deliver after quite some time, while on the agile you have 2 weeks iteration and you can change requirements and react more flexible on challenges. l had a waterfall project for a small company for video conferencing and the developers used to do the same functionality for four weeks and postponing a demo. I had to do some testing and I knew things are not in a good state and the demo to the customers was a complete fiasco, but t

    • Tom-
      I think you made an interesting point. It seems to make sense from the customer’s point of view for them to have more autonomy and thus improve the experience of their game, but ti reduced the control management had over the entire system. This is where the idea of a transition may be helpful to anticipate how this change would impact operations as a whole and try to measure efficiency early to identify where problems may arise and address them sooner.

    • The waterfall is more risky because you deliver after quite some time, while on the agile you have 2 weeks iteration and you can change requirements and react more flexible on challenges. l had a waterfall project for a small company for video conferencing and the developers used to do the same functionality for four weeks and postponing a demo. I had to do some testing and I knew things are not in a good state and the demo to the customers was a complete fiasco, but the project still didn’t fell apart.

    • Yes Margaret I agree the waterfall project has much bigger risk because you can do less changes on the fly, can make corrections and plan new things which come last moment. You can show prototypes and short wins to customers and they may evaluate if you are on the right track as well.

  • Leave your response as a comment on this post by the beginning of class next week as well as your comments on your peer’s responses. Remember, you need to average four posts a week for a B. For these wee […]

    • According to me the Path part is the most important. If the environment and the direction to drive the change is not set right and properly, one would not be able to drive the change in a right fashion. Also, even the directions are not set right, one can also not motivate the other involved people to accept and follow the change. The path can make the job of rider and the elephant easier and if gone wrong, can lead to a failure. Change itself is something that people in an organization are reluctant towards. They get accustomed to a set ways of executing their tasks. If a change is proposed, how the changes will be brought about, the pace, the fashion and the amplitude that the change will be brought very important. If these are pre set, and done correctly, the role of the rider and the elephant will be more efficient. The resistance towards the change will be easily handled and the communication pre, during and post the change will be more helpful.

      • I agree that in theory if change is addressed correctly it should go smoothly. Although I wonder what management would say about handling resistance to the change with organizations that had/have unions to deal with and the change impacts pay and jobs. For example, hospitals with allied health or nursing unions and the automotive industry. In many situations change management may be handled 100% correctly but it is very difficult to control the “Elephant”, emotional side of things, and I’m not sure there is a proper way to deal with it when strikes occur and picket lines are formed especially in a hospital environment.

        • Stanley, I agree with you that managing the “Elephant” is the toughest thing to do. But I also believe that the Path which is set not just during the process of change, but also before that, and in which a company usually thrives can make or break the situation. I think it is absolutely critical for a company to ensure that environment is always set in a way that employees can embrace change. I know it is easier said than done, but a lot of young companies are trying to do just that. Work on building a culture that is dynamic.

          • I don’t disagree with your statement. What I’m stating is that sometimes there are other situations that come into play that need to be considered. You have to consider what the union is in the scenario. Is it the Elephant with all the emotion or is it perhaps an obstacle that needs to be removed to get to the right Path to the environment you speak of? Work environments/cultures can be as dynamic as they want but when a unionized bunch of employees don’t care about those things and demand change based on what they want it is not an easy situation to deal with. In this situation, perhaps even the Rider is the most important since they would be the problem solver.

            • I think both Sid and Stanley are correct at their view point. But as per my understanding, the rider, elephant and the path are all interdependent. All the three can influence each other.I chose path as the most important as i think it is the most crucial, but cannot be the most influential. Depending on the situation that arises by the path or the environment, the rider or the elephant can become the leading role or the most influential. The path is most important as it defines and manages the change and how to bring into effect. The dynamic nature of the work culture gives the freedom to use the rider and the elephant to a customizable degree.

        • Snigdha and Stan, I guess this discussion is personal to each one of us, according to our experience with the world. I feel that the Path has to be set correctly by an organization first. Organizations usually set the path, based on the work their organization does and based on the goal they would like to achieve, for example “meaningful use” or “magnet status”. The Elephant starts getting effected after the change has been announced by each individual department or unit. If the announcement reflects a well thought out process which does not create a sudden shock to the employees; then there is more of a chance of acceptance, curiosity and support for the change. There are people who react negatively to any change. There are people who want to do what is right and necessary. There are people who accept change easily. There has to be a performance evaluation or some way to weed out, the people who will not change. If there was time to think, time to question, time to train, time to change and time to accept; there must be a time to call out, “zero tolerance” for anyone not willing to facilitate organizational changes.

      • Hello Snigdha:
        I agree that best ways to address changes in an organization is through a lot of planing to understand the stakeholders point of view and then craft the steps to notify and implement change through the organization. The planning should include how the organization defines a successful implementation. A contingency plan needs to be in place to work with those who chose not to engage with the new change.
        Best/Rogelio

      • Snigdha- I never thought of the path being established as making things easier for the elephant and the rider but it makes sense. If there are obstacles and the path is difficult i suppose it really doesn’t matter if the rider and the elephant’s needs/motives are satisfied. Personally I still operate as an rider thinking if I know the details of a change I can overcome most obstacles, but I still think you make a good point.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?
      One of the previous organizations I have worked with was undergoing an acquisition. Because a larger international media conglomerate was to buy one of the biggest media companies in the country, change of leadership and organizational restructuring was on the cards. As the CEO of the smaller organization was supposed to take over as the Managing Director of the APAC group, and teams were to be consolidated, there was a sense of insecurity across both the organizations. People were worried about losing their jobs. Finally, the first email came in from the CEO of the global organization, announcing the new elected leaders and how the new organization structure would be. A few more emails followed during the fortnight, and a town hall was announced. A large town hall where 1,500 employees was called for and the organization’s long term vision was discussed and how the teams would work together was brought up. The change in leadership was also discussed, and how that would align with the company’s goal was highlighted during the town hall. Going forward, every team was addressed by their respective managers about how things would work going forward, and how their role has or not changed. I think the communication was very effective because it came it was done all at once via the email. And to give it a personal touch, conducting the town hall with 1,500 employees worked really well, as it gave everyone a feeling of being a part of the same organization. Then the third aspect of it, where every manager spoke to his/her team made the communication very clear to all. I think the way the macro level of communication in the email and then the town hall, followed by details in the meetings with the manager helped everyone adopt to the change easily.

      • I worked for a company that a similar thing happened at and they did a similar process in announcing the change. It sounds like your company was very prepared by addressing changes to everyone even down to the individual role level. The situation I was impacted by was not as thorough and the change management process somewhat failed since it left large groups of people wondering where their place was in the new organization.

        • Stanley, it is obviously very difficult to manage so many people, especially in times of change. I think the larger the team, the tougher it is to manage change. I remember this one instance, when the team I was a part of started hearing “rumors” about our manager resigning. Because he had not told us about the same, it was difficult for us to imagine what we’d be doing in the larger context of things. Also, our manager was an absolute favorite of the team. A couple of days into the “rumors” and our manager got the entire team into a conference room, and spoke to us about what he planned to do. I think keeping communication open is the key to a smooth change management.

          • I have always felt that honesty is the best policy and it sounds like your manager subscribed to the same theory. Problems don’t go away by ignoring them, facilitating open and honest communication is a great way to distill rumors. If you don’t provide people with information they will quickly make up their own. Staying in touch with your team and personally providing them with information will allow you to keep a degree of control and not let rumors develop or get out of hand.

      • Siddesh, that’s a nice example of how effective communication can play a crucial role in the success of the change happening in the organization. A well thought strategy to all the levels of the organization via different modes/channels is very helpful. It clarifies any confusions and rumors spread in the change environment and also outlines the vision behind the change to all the parties involved.

      • Hi Siddesh. The company I work for is also going through a large merger and is in the process of getting government approvals. In your case it sounds like it was communicated well. I think the town hall is key, cause with such a big change people are definitely going to have questions and I think being able to ask in person is the best way for that. So far with the merger of my company I would say it’s too early to tell if it was handled successfully since it’s still in progress. They have communicated out information to us but since it is pending approval there are still some unknowns at this point.

      • That’s a nice example, Siddesh. In one of the organization I worked previously also followed a similar approach when the performance appraisal process in the organization was changed. The process was being used since a long time. Therefore, when there were talks that the evaluation process is going to be changed, there was a lot of confusion and apprehension among the employees. Management realized that it has to communicate about this change to the employees so that their doubts are cleared and they organized for town hall meeting. This town hall meeting was conducted by the HR for our entire Delivery Unit. And she presented the changes in the proposed systems, how the performance is going to be evaluated in future, and how it would impact the employees. I think Town hall meetings are the best way to address the issues of a group of people at once. Though, it is difficult to manage such a large group, it is an effective method to communicate. This meeting helped us in understanding the changes. Also, the Q&A at the end of the session was helpful to address individual concerns.

        • Sadhana, That’s awesome. I wish my organization’s HR dept would hold such meetings. It is so difficult to keep track of all the HR changes. I try to keep up with changes and emails but some things are not forwarded to employees. I like to know everything whether it affects me or not. I call myself a consultant because I like to help people when they have issues with certain things and if I am well versed of the topic, I will help. I have a job where I have the privilege of getting my emails daily and reading them daily. Most of the employees look at their emails once every 2 weeks. That’s because the managers were asked to enforce the biweekly reading of emails so that employees kept up with updates. Even I don’t know of HR changes until I need to access that benefit, for example tuition remission or FMLA or retirement, etc…. I may suggest this idea to our HR, maybe a yearly update. TY

        • Sadhana, even in my case, the town hall was clearly the place which facilitated better change management. To add on to that, they also plugged in people from different offices in the country, via Webex. That way, the ones who could not travel also felt included. It was a strange, emotional moment for all of us, because the acquisition was taking place, and we were e-meeting our counterparts from different parts of the country, to whose name we had never really put a face on.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective? Approximately 8 years ago my employer was freezing its “defined benefit’ plan for new participants and provided existing members a one-time choice of either staying in it or moving to a matching plan. Being an HR Rep, I was part of the communication team and as such was outfitted with a “toolkit” which was perfectly put together in a binder with Q&A’s, technical documents, printed slides etc. I was however an impacted participant needing to make a choice. I found the individual decision-making tools afforded to me extremely helpful (i.e. online modeling applications) and layman interpretation of WHY the organization was doing away with the plan thus forcing me to make a choice. Such explanation included a benchmark analysis showing that our plan wasn’t competitive for the workforce, the cost of the plan versus returned benefit, ect. The project concluded within allotted timeframe with very little “noise” and was overall well received.

    • Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?

      To me the most important aspect that requires the most care with change is the elephant. The Rider tends to be the rational part that deals with plans and provides analysis on the path to change. The Rider can provide the analysis for which path to take to change and remove the obstacles but if the Elephant isn’t going to move than nothing happens. The Elephant is the emotional side that deals with the real power in accomplishing the journey to change. If the Elephant refuses to accept the plans and analysis for change than the Path to change doesn’t even matter. The Rider has to tap into the emotional side of the Elephant to get them to accept the change before the Path can even be discussed.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?

      A few years ago when I was still working as a clinician in the hospital my manager announced the department was getting a new lab machine to run arterial blood work and that everyone had to have training before they could use it. She had 3 shifts to deal with and weekend personnel who never attended the staff meetings so she knew she had to make sure everyone knew about the change. The announcement was first made at a scheduled staff meeting 3 months prior to getting the new machine. She also mailed letter to everyone’s home and sent emails in addition to having postings all around the department. There was also a “News Board” in the department where everyone had to read and sign any new news or meeting minutes posted.
      For the training she had the company’s implementation consultant schedule times over 2 weeks between all the weekday and weekend shifts to educate the staff. One very important administrative aspect she did was to get authorization from the hospital to pay for the additional education/training time if people came to the sessions during their off time or hours prior to their shift. Department educators were assigned for all shifts to be the SMEs and learn from the consultant all the process steps for the new lab machine. She also posted the manual from the company and her own written interpretation in case the company’s manual was too technical for someone. The last thing she did to complete the change was filmed a video of herself working through the different maintenance and usage processes and posted it to the hospital intranet. In the end, she was not only thorough in the announcement but she was equally proficient with getting everyone the training and paying for people to get the training.

    • Wow Stanley, looks like the manager did all her due diligence before the change actually occurred. Although I wouldn’t have liked my office sending me mail at home, I think the manager did her best to bring to attention of the employees the change. She tried to use multiple ways of communication, and most importantly took responsibility of what she wanted to achieve. I loved the way she also posted an interpretation of the manual for stakeholders who found it very technical. Indeed, a great example of how one can effectively communicate change management.

      • It isn’t unusual to get “mailers” if you are a clinician at a hospital especially if you are a per diem worker who only works maybe once a month. Even today there are people who do not use all the technology that is available. Many still do not have or know how to use email or text on phones, etc. For those people the only way to contact them is by phone or mail. For a department manager in the hospital to call 75 people is a bit difficult so you’re left with old fashion mail.

    • Maria, this is a good example of how change management took place in your organization. I wonder how easy or difficult it was for you to convince people of the new plan (or the other one, whichever was better). How did that go? Did YOU as the HR representative who was facing the people face any tough questions or scenarios?

      • Sid, Our job was not to present one plan as better than the other. In fact, it is a very personal comparison. For example, I knew that I would likely stay with the organization for a number of years and consequently remaining in the old plan was better for me in the long run. Yet, my situation at the time warranted me choosing the new plan as I was unmarried and would have forfeited the entire old plan benefit if I died, leaving my sons with no benefit from that plan. The new plan allowed me to name them as beneficiaries, i.e. inexpensive life insurance. I shared my personal decision-making process in meetings that i facilitated to make people feel comfortable. They knew that my background was in pension plan so hearing from a SME about her own tough decision made them feel more confident & comfortable.

    • Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?
      I believe that elephant is the most challenging part of the change message and therefore should be constructed with utmost care. The elephant is the emotional part, and emotions can be unpredictable. Rider and path have to do with strategy and communications which can be approached I a step by step manner. The elephant on the other hand involves group phycology and appealing to the crowd.

    • Hi Stanley, looks like the manager covered all the ways she could send the message across to employees. But at what point does such communication become annoying? I wonder if she had any resistance when she was implementing this change, maybe from the management for funding training?

    • One of the most important aspect of change message that should be looked upon carefully is the Elephant. Elephant which basically represents emotional attributes of the individual is the key element to watch for in the Change Management journey. Often people might drain out in accepting and changing their behaviors or get insure of their jobs or just get frustrated of the environment that can negatively impact the organization to move ahead with the change. Outlining the right communication strategy which motivates people through the various phases can enable in an efficient change process. The aspect emotional changes is also captured in the concept known as Valley of Tears. The employees in the firm have apprehensions prior to the announcement of the change. The first official announcement takes employees into shock as they are unsure what to do next and thus their productivity decreases. The defense reaction which follows the prior stage leads to a short term increase in productivity. In the next phase, employees as even though they understand the need for change but gets frustrated as they do now know strategy for change. Then follows the stage of emotional acceptance and employees loose their known behavior. Next follows with a move towards learning through trial and error method. At the end, the employees integrate the changes in their behavior and this enables to see a first real gain in productivity. Thus, as employees go through enormous emotional pressures and phases, it becomes highly critical to plan and articulate effective communication mechanisms to take the employees through the change process.

      http://www.affectiveconsulting.com/change-management/

    • Maria, its a nice approach that your company outlaid and provided enough empowerment to make the change successful. In my prior job, there was a time when a new client was tagging to the consulting company in which I worked. As part new set-up that was happening, we had to gather information from the other vendors of the client who were moving out (as our company was replacing them). There was not a very efficient system set in place to capture information from the vendors (who were moving out). It was just communicated in our stand up meeting to capture as much information as possible which did not worked out very well. Anyone was asked to take information for any application. But as time progresses and as people started to work on the applications, they became more knowledgeable about the systems and applications in place.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?

      At my job we have a change management process so that anytime a change is needed in our production environment a change ticket needs to be opened. In the ticket you need to include several things such as: the application(s) you want to change, the steps you are taking to implement the change, the time and date of the change, the reason for the change, any risks involved, if it is possible to back out of the change, and the names of the people needed to approve the change. There is also a CAB (change advisory board) meeting to go over the upcoming changes and answer any questions. While filling out the change ticket can be tedious, it definitely helps other people that need to reference the details of the change since there are often multiple people involved (anywhere between 2 and 30+). This helps me when we have our monthly changes go in. I can look at the plan ahead of time and see all the steps involved and what part I have to complete.

      It was effective because I could see everything in an organized format and it breaks down a complex change into smaller manageable pieces. Also, it helps me understand the big picture. My part involves pushing the code into production and ensuring it installs correctly. However, I don’t actually develop the code, so I like to look through the change document to see the specific fixes and features that are going in.

    • Hi Maria, I think when a change like this is occurring it’s important to be transparent and honest with employees, which seems like how it was handled. It helps that in this case the existing members had a choice of staying or moving to the new plan. Sometimes people are not as open to change if they don’t have options to choose from.

    • Hi Stan, I agree that the elephant is the aspect that needs the most care. When dealing with change, the emotional aspect can determine if a change will be a success. If people don’t feel good about the change than it most likely won’t be successful even if the the rider and path are on track. They will be more hesitant to accept the change even if it is ultimately for the better.

    • Hi Swetha, I agree when dealing with the elephant or emotional part it can be unpredictable. In a way it reminds me of the ongoing presidential primaries. Having an election involves a lot of change, and you can see in the polls that candidates will often go up and down and I think this is the result of people’s emotions. Even if a candidate has a steady rider and path, it is most important to manage the elephant because people will often vote on their emotions and what they are most passionate about.

    • When you have to do a radical organizational change is very hard to change the attitude of some employees and management who has done the business for 2-3 decades in the old way and all of sudden you come up with new processes, systems and innovation. The people are used to do the things the old way and it’s very hard to take the change the elephant part because they think the old way of doing things is the best way and they are just not giving it up, its in their minds.

      • Bisser, I have certainly worked with people like this who are very stuck in their ways and unwilling to change. It can be very frustrating, especially when the benefits of changing to the new system are so apparent to everyone else and the few stubborn people keep the change from happening or being as effective as it could. I think a big component of this is people being ok with a process simply getting done and they are not concerned with process improvement or efficiency.

        • The worst part in those cases Lauren is the team continues to repeat the same old mistakes and miscommunication, because the processes are just not functioning as expected. The frustration is just a stage in the organizational development, but in certain occasion there is a need of radical change of processes from the rider and enforcing the path rather than waiting the things to change on a good will and desire. The elephant has to be cut with a surgical precision from the people who are not giving it up from their minds.

      • Bisser, The un-changeable Elephant minds are the most difficult to work with. That is why I support the “zero tolerance” policy in today’s work environment because that is the only thing that will bring fairness to all the employees. I feel that everyone must follow company rules once decided and notified. Those who feel that they can do whatever they want, can do out the door. There are rules everywhere, we must all be disciplined in every area of our life especially when our work affects others.

      • Hello Bisser, nice point that mature professionals are set in their ways and its hard to change how they think and do things. When I was a Bristol Myers Squibb the company was rolling out an IBM platform company wide. No more Macs or Apple computers in the workplace. The researchers resented the business folks for taking away their computers and giving them IBMs. How BMS rolled out the change was to put a home screen that looked like the Apple/Mac homescreen. Then have the program icons look like Mac/Apple to get them moving. The challenge was the Word and Excel did not have the same function labels as the other machines. The approached worked because the Scientist felt some relief by having a computer screen that resembled an Apple/Mac. However, this worked and soon everyone in research was on board using the IBM platform.
        Best/Rogelio

      • I agree, people who work in any environment who have been there for a long time do not like change and like to keep things how they are comfortable with. A lot of times I think age has to do with this and with technology advancing more and more older workers are not fascinated by it, thus would not like to change their ways.

    • Jonathan, I also think that having to fill out the form makes the change maker / person filling out the form think all aspects through and keeps him/her from forgetting any components. I am guessing the form is likely for this reason as well! I am curious if you think the form always works or if it needs to be altered for particular situations / changes / parts of the organization. For example, if the form does not capture all of the specifications for a particular type of change.

    • Once they released the CEO, CTO and the VP of eCommerce development of one company I used to work ffor. The message was following the company was losing revenue of sales and software is not preforming as expected for the money and for time what was presented by the senior management. The message was clear that we need change and we need to get back on truck for sales and technology, that’s why we need the change,

    • Hi Swetha, I agree with the emotional part there are many employees who gathered emotions with the years of service, sometime decades, they are having certain work patterns which are very hard to change or to break, its hard to make them to give them up and go through new paths, The rider needs to try step by step, but this may depend on the circumstances and on the schedule of the plan for change.

    • Wow! I’m really impressed with your manager’s thoroughness. She really covered all the bases. I had a similar experience with training employees and know that paying employees for their time during training is hugely beneficial for attendance and morale. The aspect I am most impressed with here is that your manager not only wrote her own interpretation of the manual but also took the time to make tutorial videos. I think it’s pretty safe to say that no one had an excuse to not learn the new system. This change was clearly very important to your manager and it sounds like she went above and beyond to make the transition as seamless as possible.

    • In my most recent role, we went through a software change that would allow our members to access the website and book tee times for themselves at either of the two properties owned. Management did a good job of communicating the change to us and incorporated the rider, the elephant and the path into the message. The rider was somewhat obvious, through time the system would create less phone calls for us and allow members to book their own times pleasing both parties. The elephant was more subtle, but they anticipated anticipating some of the downsides to this new system including: limited initial functionality, adapting to the new software on both the employee and member side, and less control over the tee sheet. They communicated these concerns to us and by doing so eased concerns of on-going issues. The path was laid out well because the changes were made during the winter off-season months making the transition easier. Most importantly we received a good deal of notice and one on one support with the changes.

      • Hi Thomas,
        It is a good example which includes the utilization of rider, the elephant and the path.
        I am wondering what kind of channel did your company use for communication. Any difference between the message it delivered to employees in different positions? How did it deal with resistance?
        As the employee who were affected by the changes, which approaches (the rider, the elephant and the path) are most effective to you?

      • Tom-
        I agree, some changes are better communicated when they are expressed ahead of time. It seemed this allowed people the time to process, ask questions and accept the change being implemented. You also used a word that I think is very important but not always considered, “transition”. I think transition is a period of time that is sometimes overlooked or forgotten about when a change needs to happen right away. However, I believe the more successful the transition, the more effective the change will be.

    • I agree with Lauren that having to explain how you plan to implement a change, the deadline, etc. is a good way of making the person suggesting the change to really think it through. It sounds like these forms would be useful is someone submitted a change, but left the company before completing it. Has that happened? How did you handle it?

    • I agree that crafting the emotional message should be done with the most care. Most managerial decisions are made with logic in mind, so it should be relatively easy to explain the reasoning. Considering and addressing all of the complex emotional impacts a change decision will have is much more difficult.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?
      When the president of my company decided to retire and a publisher who had been with the company for 20+ years stepped in to fill his place, they held a wine and cheese event in the conference room and made the event mandatory for all employees. The current president announced his retirement and gave a speech explaining why the new president was taking his place. After that, the new president spoke and explained other position shifts based on his changing role. After the event, HR sent out transcripts of both speeches and encouraged anyone with questions or concerns to reach out. Top management below the president had been informed of the shift weeks prior so they were available to answer any questions their direct reports might have. For a relatively gossipy company, I was impressed with how they concealed the retirement for so long and quietly set up a succession plan. It helped that the new president had worked with almost every group at the company so most people knew him and enjoyed working with him, whereas the exiting president was more aloof and rarely came into the office.

    • Rishabh, I have definitely experienced going through this progression of reactions due to a change. Growing pains are an unfortunate side effect of change. A good manager can express empathy and understanding of these issues reinforced by providing a reminder of the logic behind the change to make a transition as smooth as possible. You may not be able to completely avoid “the valley of tears”, but you can do your best to minimize the effect. Thank you for the link.

    • I worked in a manufacturing company in my home town and the company did a really good job to communicate with us while it decided to switch the CRM supplier and upgrade all the system. First of all, our CEO and general manager were totally committed to the changes. After strategy committee made the judgement call, our general manager immediately formed a cross department team including IT, HR, marketing and sales department to identify the changes and impacts in each department and related employees. The team members belonged to different departments also need to join the external training, be familiar with the new software function and become the “coach” for his/her department to pass the knowledge to other peers. Before the system launched, our CEO wrote the internal memo to address the reason for switching and emphasize how the changes will help company growing. He also gave the clear outline about when the internal training and testing would be conducted and the exact date that we would officially launched the new system. The HR and marketing department also produced series of posters and training packages based on the need of departments. In less than 3 months after CEO officially announced decision, the company successfully switched the system and utilized the new functions.
      As the employee who were highly effected by the changes, I think the company did a really good job to deliver the reason of changing and explain honestly for the impact and inconvenience during the switching. It also provided the solution and schedule for training as well as testing. Furthermore, our CEO and general manager kept discussing the issue in every meeting and internal notes, revealing their determination and faith to implement the changes. As the result, most employees could quickly accept the situation and immerse themselves in the training instead of not cooperating.

    • Hi Colleen,
      It is a really good example! I am impressed by how management level could keep everything quiet and delivered the full pictures in the meeting at once. I am also curious about did the HR department or new president continue the communication about the changing after the event and what kind of action that they took?

    • Pei Yen, it is great that your company not only stated what the change would be, but also provided a timeline and guidance for how employees would learn the new system. It sounds like this was an effective way to gain buy in from various departments and employee levels. Additionally, having a CEO and general manager that were committed to and knowledgeable about the new system likely eased any concerns employees might have had.

    • Maria, i liked the approach taken by your organization to conduct the change. With what you described, it seemed to be disciplined and in sync. It was interesting that you were involved in communicating the new change as well as the customer being effected by the change. Can you let know some of the difference or similarities playing the two different role and to what can you relate the best, the elephant, rider or path?

      • Thanks for the challenge Snigdha! Sticking to this example, I related best to the Rider as I was adept at translating legal and actuarial language to layman terms and in turn was able to confidently support the “why” and “what we need to do”. Incorporating my personal situation and decision into the conversation was extremely helpful, as I had said, in formulating the message to the Elephant. I recall in a few of the sessions that I facilitated asking some of the audience to share their own personal situation and together we helped the participant think through the alternatives. We engaged in conversations using real experiences as our topics. That said, mind you that there were associated cost containment efforts over the past ten years (think Retiree Medical liability) that had laid the groundwork for the “path”. That is, ten years prior, we had begun to limit future Retiree Medical participants again using the story that the organization’s resources could be best applied elsewhere (and it was true!) – current, comprehensive family coverage, healthy lifestyle benefits, etc.

    • Hi Stan, i see that how much you emphasize on the elephant as being the most important aspect that requires the most care. I on the hand stand for path, and there are some that thinks riders require most care. I wonder that does these selection changes as per the scenario or these personal preferences. I cannot say that any of the explanations proving which one is the most important is wrong. Each seems to support their choices well. What i get out of all these that if any of the three lack proper care, the change will result into a failure (although i still vote for Path 😛 )

    • Yes, giving our employees the option was a BIG seller EMOTIONALLY. We were not required to do so by law and in fact most organizations did NOT allow for such a choice. It really drove home the point that the organization was willing to forego some cost savings in support of the emotions faced by staff.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?

      Our institution announced that it will be moving to EPIC, an electronic health record (EHR) system. It was announced 1 1/2 years before the “go live’ date. There were lots of department/unit meetings with our unit managers. Then there were meeting with the CEO, CIO and the CFO. The employees started to learn the plan: the plan of having subject matter experts (SME), from each area and champions from each type of service. The employees were told that if they were a SME, their shift would be covered by additional staff pre-scheduled for those days. The employees felt very relaxed because they did not have to worry about their shift or their unit or worry about returning to their work area quickly after the sessions! The plan seemed more thought out. Everyone knew the plan. There was time to learn and experiment with the forthcoming EHR. WE met with many of the IT analysts on each team for each area. Their was at least one familiar nurse on the IT team with the IT analyst.
      Lot of the ingredients of effective change was present: notice of plans well ahead of “go live” date, steps of plan, people involved, people in charge, training, descriptions of SME and champion roles, input from SMEs, online training and simulations and team meetings to enhance group cohesiveness and comfort. All in all, I felt very satisfied with the process.
      Later, due to inter-operability issues, the go live date was moved to August 2016. Even that, was a difficult but great decision as they recognize that time is needed for proper installation of the EPIC EHR for end-users.

    • Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?
      Well, the elephant because it is the biggest and if it decides to go out of control the rider has no opportunity to redirect it. The elephant can make its own path if the need arises. The rider goes where the elephant decides to take the rider because the focus or motivation was lost. In this example the elephant is the irrational self and the rider the rational self. The challenge in constructing the change message is that we need to give the elephant the option to cooperate with the change. To get the elephant in a cooperative mode we need to give the elephant something it wants or likes, a happy place. Like a bag of peanuts to get it moving in the chosen direction.

    • Good questions Pei Yen, the message was communicated differently internally and externally. Internally we were lucky to be part of a small organization where information flows quickly so information was disseminated mostly in small meetings or one on one. Externally we communicated the change to our customers by way of our email listserv, newsletters, and reinforced this with face to face encounters. To me the rider is most effective, if I think an idea is a logical one I will usually be able to bring myself on-board despite the growing pains that may be associated. I did appreciate the consideration given to the elephant and path in this scenario though, it shows thoughtfulness and respect to make transition as easy as possible.

      • Hello Thomas I like your example of the rider, the elephant and the path. What i like about it that changes goes smoothly when the affected parties feel their situation has been taken inconsideration as part of the decision to implement this change. I have a question, did the golf club make more money as a result of the change? Like what was the financial outcome of this change.
        Best/Rogelio

    • Susan, sounds like they did a really good job of giving you advanced notice and allowing you to experiment with the new system. This must be especially important in healthcare whereas you are not just dealing with customer service (as in my example), but you have lives on the line. Mistakes are much less tolerated in this environment and it sounds like due diligence was done to make the change as effective as possible.

      • Thomas, I thought it was a well thought out strategy. The technical side is so difficult to predict as interoperability sometimes cannot be diagnosed until it is put to test or until you discuss the needs of the individual department. Then all of ta sudden, you have a glitch. But I feel that it is better to know ahead of time and fix or recalculate before it goes live.

        • I like the level of communication and the lengths that Temple went to make you and your colleagues feel at ease. It’s a good sign especially for a Hospital as large as Temple. I am curious, how well did they communicate the change in Go Live, and do you think it will change their previously communicated plan?

    • Hello Maria, I am guessing the cost benefit analysis help ease the tension when the participants realized the change was in their best interest. Do you remember how many participants decided not to make the change in plan?
      Best/Rogelio

    • Pei Yen, that’s a nice transition path to the new change happening in the organization. Keeping all the parties involved, spreading the word across via posters, meetings and emails, and also letting people know about the reason behind the change. A strategy which could minimize the resistors in the change process. But I am just wondering how big this organization was and were there any effect because of this transition with the dealers/customers the company dealt with.

    • Swetha I feel that it may all depend on the number of employees. If we are dealing with 15 or 20, elephant approach may work if it is not a unionized environment. If we are dealing with 1000 employees, the elephant has to be embedded in the path. If it is a unionized environment, there will have to be union, elephant meetings before the path is set and then the issues are handled prior to posting the path.

    • Hi Stanley, I came to the same conclusion. The elephant is your irrational self and no matter what kind of contingency plans you have to keep it in check once in while everyone just flies off the handle. After its all said and done you (the rider) begin to think logically and realized you may have over reacted, not lot just a little.
      Best/Rogelio

    • Colleen, You are right. They sure kept a lid on it. I like time to get ready for the party, that ‘s any party. I like to know, what to expect. For example, when I sent our invitations, I try to include a dress code, be it casual or dress. I want everyone to feel like they fit it and were included when they arrive at the party. Same with meetings, I like to know what I am walking into. Unfortunately it takes me time to adjust to some surprises.

      • Susan, I totally understand and I am sure some people felt that way about how the change was announced. Because of the gossip culture at the company, I think they had to keep a tight lid on it to avoid rumors of layoffs or negative fallout of the change. How would you prepare people for a meeting about leadership change?

    • Jonathan, any kind of merger or acquisition takes a toll on not only its management, but also the employees. I think it comes at a right time, as you will get to experience it first hand, how change is managed. I’d be happy to hear about how it went 🙂

    • Hi Colleen, That’s a nice example. It is quite difficult to deal with management changes as employees are often worried about the new manager and how things would change because of new team/new manager. And, this was handled really well. Explaining why the position was handed over to other person would help employees in understanding the situation and they’d know what to expect. And, as the new president also continued to communicate effectively, this would certainly make the transition quite smooth.

      • Sadhana, yes they created a dialogue around the change and helped people feel comfortable speaking up. I think that the new president was well liked and well known was a huge help as well. People already saw him as a leader so it was easy to think of him as the leader of the whole company. When a change seems like a natural progress, people seem to be more accepting (or at least understanding).

    • I thought about it for a while and I think the rider is probably the most important part. Yes, clearing obstacles is important it makes transition smooth, but I think getting everyone on the same page with the same message is very important. No matter how many obstacles you remove the change won’t happen if people don’t believe in it.

    • That’s a really nice point! If people are not willing to change then no matter how much efforts you put on improving the environment, that would make no difference. I agree that emotional appeal needs to be made for people to accept change because at times, people are not satisfied with only logical arguments.

    • Hi Rogelio, Yes, for most, staying with the Old plan was the better choice but I did explain why I switched and I stick by my choice! less than twenty percent actually switched to the new plan so I suppose despite our efforts, folks didn’t like change! that said, and although I was not privy, I am certain that some baseline % was the goal and when we talk pension expenses, that baseline did not have to be very high in order to reap some immediate gains. It is really the organization’s future liability that needed to be reduced. At the time, strategy likely predicted our growth so we achieved our goal.

    • When we transitioned to our latest iteration of the KIDS Plus IIS we had many meetings covering how and when the change would take place. We also had multiple internal training sessions for our staff and were provided with a plethora of training materials so that we could train provider, which we did over the course of a week. I thought our transition from the old system to the new system went very, surprisingly so given the enormity of the change. I think what made it so effective was that everyone, starting from our leadership down to our clerical staff was excited about the change. The enthusiasm spread from the top down, and I can’t recall any resistance to it. It was made clear that our lives would be made much easier with the incoming change.

      • John, the situation that you have stated where the team went through lot of training’s reminds me of a transition that was happening in my prior job. There was an ITSM tool which was used to capture daily incidents that were logged by the users. Our team was tasked with picking up a new tool which was considered to be more effective (in terms of noting the time for resolution of logged incidents) and user friendly. As part of this change, the team was provided with lot of regular training’s by the Tool Champions that enabled us in smooth transition.

    • That’s interesting, when we were discussing this in class. I almost felt like it was bullet points of how to approach the change, Rider first, elephant second and path third. That being said, I can see where you are coming from too, just a different perspective on how to approach the situation. One important thing that I have learned during this class is that the inability to be flexible with your approach is a good way to doom your project. So feeling out what will work best for your project and company is important. It seems to be one of the most difficult aspects of project management- knowing your staff and environment.

    • Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?

      While elephant, rider and path are all important, I believe path should be constructed with utmost care because the environment and culture matters a lot in driving the change. It should be set so that it motivates people to embrace change. Probably that is why companies these days give a lot of importance to work culture as it does have a significant impact on the work done. That said, I also think there is sort of connection between all three and they influence each other at times.

      • Hi Sadhana,

        I agree with your response to focusing on the path and the culture as the reason why. I work at two health care systems at some point in my career that had gone through financial difficulties and needed to remove some positions and freeze hiring for vacancies. Company A did an excellent job in keeping the employees involved and informed of the changes to come and where everyone were in the company’s new path. Employees who job’s positions were immediately discontinued were allowed to look through existing vacancies apply to and continue on to another career path within the company. This resulted in a smooth transition 85% of those involved. The other 10 and 5% retired and accepted other employment outside the company. Company B went through the same financial issues, but left it’s employees wondering at all angles as to who, when, and where the cut backs would happen. This resulted in a mass exodus of employees from highly critical areas and back filling in a timely matter impossible. This was due to the distrust of the company. Company A & B had drastically different cultures and outcomes yet shared in the same issue.

    • John, you make a great point. Without buy in from the team, a change will not stick. Much of implementing any change (whether it is a personnel change or a new ERP system) is managing relationships so the Rider is an integral element of the change process.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?
      When I worked in performance improvement in behavioral, I was responsible for reporting sentinel events to the Joint Commission along with a root cause analysis. There was a change in the reporting criteria for what made an incident “reportable”. I used to have to report every suicide attempt (since our patients were outpatient, we averaged 2 a month). The reporting requirements changed to only needing to report suicide attempts that resulted in death. This change was communicated in a number of ways. They announced it in their monthly newsletter that the change was being made so people were aware ahead of time. They also announced it in their meetings with top management so even if you missed the newsletter, key staff were made aware to pass the message along. This was effective in that we were notified a month ahead of time that this change was being made and the new definition for what was considered “reportable” was given to us in case we had any confusion. This was also effective because they re-announced this change in a meeting that was closer to the implementation date so managers could announce the change to relevant staff in case they missed or forgot about the update in the newsletter. This was then followed up by a system wide email so everyone who works with patients were aware of the change.

    • Stanley-
      I’ve definitely worked with many elephants and agree they require a lot of care to accept a change. I think tapping into an emotional takes a lot of genuine finesse and empathy which can be more difficult than providing facts or constructing an optimal environment for change. I’ve worked with a number of people who understood what the change was and the benefits but they were so deep in their comfort zone their resistance overcame any rational logic. Most instances, these people actually left the company because they could not be emotionally swayed. I agree elephants require a lot of care, but I think what makes an elephant unique, is that they have to be open to emotionally accept the change.

    • Swetha-
      I agree the elephant requires the most care. I also think it’s the most difficult to reach on a large scale. Most changes happen system or organization-wide. It is easy to send out a mass email notifying everyone of the change, the rationale and the obstacles or path to come as a result of the change. The elephant, however, I think is more specific to an individual. I can understand the value in tapping into someone’s emotions to motivate them to change but emotions are very personal. One message could tap into my emotions but not someone else’s. I think appealing to the elephant takes a degree of individual attention that at times is just not practical. The only way this could be handled is if a change came from top management but was left to individual supervisors to implement with their staff so that individual attention could be provided to the elephants.

    • 1.Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?

      I think the path change message should be constructed with the most care. In my opinion, this approach would effect the largest number of individuals negatively or positively. It involves making changes to the environment to produce a desired behavior that has less resistance, can create positive habits through actions/triggers that promote a detailed planned action for the employee to produce, and shows public praises for good results. The path should be carefully detailed since others will use that direction when searching for guidance or creating the direction.

    • Hi Rogelio,

      I like your explanation as to why the elephant should be constructed most carefully. I felt like the path is the most critical, but at any point the elephant finds an irrational reason as to why my path should not be the road traveled, it could easily change direction and disrupt normality.

    • Colleen-
      I’m not surprised that an event was held to celebrate someone’s retirement, but the fact that they considered and communicated the changes that would be made on other jobs is quite impressive. This demonstrates that leadership was not only considering top management changes but system change as a result of the promotion following your current president’s retirement. Also, asking for additional questions I think is sometimes done as a courtesy but it seems your HR department was well equipped to answer questions and felt it was important to include all employees in this change which I think says a lot about the culture of your company.

    • Hi John,

      I see your point, but could you agree that the path could create an environment where people could “buy in”. The path would have some obstacles since nothing’s perfect and that would present itself for reasoning.

    • I agree that with emotions things can always be hard to deal with. The emotional part or person always seems rather tough to deal with because as you state it is unpredictable and can be of anything, thus it is hard to manage such aspects or even people.

    • Communication and getting vital messages written to others seemed very critical in this process and worked! I like how the president was explaining everything before he left so it did not leave others puzzled and they knew what was going on.

    • Which aspect of a change message do you think be constructed with the most care: rider, elephant, or path? Why?
      I think the elephant seems the hardest to deal with because emotions seem pretty tough to deal with in general, so in the work environment dealing with the emotional side seems rather difficult to me, therefore it should be handle with the most care. Rational sides need care as well, but since they are rational and are controlled and have some analytic side to it that kind of cares for itself in a way. Unlike the elephant which is strictly emotions and irrational therefore I think it needs the most care so that things do not get out of hand. Emotional children are often harder to deal with and need more care than non-emotional ones, therefore I think the same can be said here.

    • Hey Susan, it is an interesting point you have brought up. In class we learnt about the framework to apply to implement change. BT the framework doesn’t specify to what extent to apply the concept of path, elephant and rider. It depends on the perspective of the executer, the importance he gives to each of the steps. This is why some projects failand some don’t – because all the steps are not properly implemented

    • Hi Rikki, yes I agree that communicating to a larger crowd and managing the elephant of every one in the organization can be extremely difficult. Like Susan said, in such situations the elephant has to be embedded into the rider and the path. The rider must be able to communicate well to the middle management, which then trickles down to the lower level employees. I think the key to this is using various touch points to communicate with the different levels of the organization. As discussed in the previous posts – emails and Town hall meetings seem to be working well.

    • Hi Johnathan, seems like change management at your organization is very structured and process oriented. I think what you are talking about a systems change. I have come across similar systems in all the company’s have worked for. The change management tool is a very effective way to keep track of change tickets and know who has made what change. It is very transparent and I’ve seen it work well especially when the teams are big or are spread out in different geographical locations.

    • Hey Susan, Its good that the announcement was made 1.5 years before the change will happen. It takes a long time for change to happen, especially in large institutions. Looks like the management was able to anticipate how long it would take and nailed it with the communication. I hope the system does go live in the newly proposed date.

    • Rikki, the recurring communication that you have outlined definitely plays the crucial role in the success of change. One of the situations that I can recall from my previous job was that there were times when employees use to implement changes(a fix for web applications) in live (production) environment directly. This was because the team was new and things were just shaping up. As a result of it there were few cases where the fix did not went well and came to notice of client and the management. After that a proper set of procedure was outlined to implement changes in the application that were in place. This new procedure was communicated to the entire team via email and also reiterated in the fortnightly meetings for couple of months which ensured the team aligned to the new process.

    • What a great way to put a positive spin on a big change! I agree with others that making the announcement in a casual way was likely beneficial to keep everyone calm, since the change was affecting everyone. Also, it seems like top management did their due diligence with planning the communication, transcripts of the speeches and any likely questions employees would have. Also, the wine and cheese party makes puts emphasis on the transition being a positive thing for everyone.

    • Describe a situation, in your own experience, where you had a change effectively communicated to you. What made it so effective?
      In my previous position the venue that my office was in (we were the exclusive caterer so a few of us worked out of the venue) did a big restructuring, which meant about 80% of peoples roles and responsibilities changed. We had weekly meetings with a few people from the venue (heads of each department) to go over our event schedule to ensure there were not any conflicting room reservations and it was during this meeting we were first informed of the restructure. We were told it would happen in the coming weeks and would be given a full account of everything shortly. Once we received an email with a detailed list of everyone’s new title and responsibilities we then had a meeting to go over everything verbally. It was helpful to get the information in writing and verbally and I felt like I fully understood the restructure after receiving the information in multiple ways. Additionally, during the meeting we were able to ask specific questions, i.e. who we should direct particular events related questions to.

  • Leave your response as a comment on this post by the beginning of class next week as well as your comments on your peer’s responses. Remember, you need to average four posts a week for a B. For these wee […]

    • Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!

      Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!

      One example that comes to my mind is a project that I worked on during my internship last summer. I was helping a biotechnology company with its digital strategy. As the company had acquired many smaller tech firms in the bay area, there were processes that needed to be streamlined. One instance would be of a product launch. Because the products that the company developed were complex, and needed some kind of instructions, the product team would hold live seminars where they would not only launch the product, but also talk in detail about its specifications and use. The smaller tech firms that were acquired would also have their own product launches and online seminars. Because the smaller firms were planned to be brought under the company’s umbrella brand, their strategies had to be streamlined. Now, my role was to create a year-long digital strategy for the umbrella brand. While working on the project plan, I obviously had to keep in mind the different smaller companies that were acquired and come up with a plan that would encompass all the launches and promotional activities. In my plan, I included all activities that would be conducted, different teams that were or would be in charge of those activities, the amount of time they would take for the activities, the overlap, etc. Because there was some kind of projection involved, I had to keep in mind dependencies, and the “critical path” in every case. Sometimes it would be the marketing team taking longer to create a plan, and others it would be the product team giving in-depth knowledge to the marketing team about the product. Although I did not literally use the PERT chart, I extensively used the Project Plan format to ensure where the overlapping was, and where the slack time would be available.

    • In my current project for Meaningful Use stage 3-CCDA I was asked to estimate rework that needed to be done due to a last minute change in one of the requirements. The estimate was broken down into several pieces. First the coding had to be broken down into 2 parts so I had to find available coding resources with the right skill set and who would provide the highest quality. After the coding resources were selected we estimated the coding based on the maximum amount of time it would take to be finished and unit tested. The minimum was 3 days and the max was 1.5 wks. Then I had to determine the amount of time to rebuild the content using the new code work. Since I was doing this work I knew the exact amount of time it would take with was 3 days max. The integrated testing workflow was still the same so nothing had to be added for that. After the estimates were complete, the team looked at the deliverable timeline to determine if we could make the release or management needed to request more time from the program. In the end we estimated 2 wks to get the task done and ready for integrated testing but overall it took 1.5 wks and we made the deadline with a cushion. In the end the estimating was done with the critical path method using the maximum amount of days to get to each point in finishing the task.

      • Hello Stanley, I am not sure how sourcing contract works for code projects. Are there different scales depending for the level of software engineer that is going to complete the job? Like one price for entry 1-3 yr experience, Masters level 1-5 yr and Senior software engineer and this forms the basis of figuring out the cost and duration of the project?
        Best
        Rogelio

      • Hi Stanely,

        This is a good example of estimating a timeline by understanding your resources at hand. The breakdown looks like a lot of over time and mildly stressed workers, but only for a minimal period of time, but the planning seemed right on point.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?

      During my internship last summer, one of my role was to create schedules for projects. I would be given a date by which the project had to be released. With that date in mind I try to calculate backwards how much time could be allocated to each teams, and how much time could be a buffer. With these rough estimates in mind I would then approach the engineering, quality assessment (QA) and user experience team leads for an estimate. Sometimes, the engineering team may request a further breakdown of tasks to help them estimate their work. In such cases, I would schedule a meeting with the developers, team lead and the project manager to breakdown tasks and decide on an estimate. I also have to take into account availability of resources such as shared resources and vacation time. In case of shared resources, I need to understand how many hours per week they can spend on the project. The QA team is usually very busy and the testers are usually working on multiple projects. The sooner I block those resources, better chances they are available. Based on the time take by the same teams to complete previous projects, I have an idea of how long they should be taking.

    • Estimating is something which I have always found very challenging, Swetha. It is interesting that you had to break down the project tasks to very micro level. I believe it was also a cause of resources working on multiple projects at the same time. It must have been tough because sometimes it gets difficult for a person to change focus from one project to another. Also, if something is on fire on a different project, that resource might give your project little priority during that specific period. Did you face any challenging situations? In my experience, I have seen that developers usually give a larger range of estimate timeline than they would usually take. Did you face a scenario like that?

      • Hey Sid, yes it may be difficult for resources to focus on different projects. Sometimes its the same task to be executed in different projects, so its not too bad. Priority issues take place very often. On such occasions the project managers need to step in and agree to share resources a certain way. It is very important for PM’s to maintain a good relation with their peers and those above them. Higher ups tend to be more accommodating to change in release dates if the PM’s maintain a good rapport with them.
        Developers almost always give a larger estimate timeline, it is the PM’s job to stay alert to it. As a PM you are knowledgeable about how long such a task usually takes, and the level of people required to accomplish that task. It is definitely a tough battle to fight. On the other hand, developers cannot take too long, because then they will get a reputation of being slow and not abiding by the timelines.

    • Sounds like your project was across companies and you controlled the WBS from the “control account” level with each account being a company then a more granular breakdown was done based on the activities each company had to do. Being a PMP I look at the CPM and PERT as two different things and used at different times. CPMs are generally used at the activity task level with a WBS to develop a schedule whereas PERT is used to estimate costs using 3 cost levels than a standard deviation should be calculated. It would be interesting to see how many dependencies there were between accounts, and how the overall PERT was determined based on the CPM.

    • What you were asked to do is difficult. On one hand you’re given a release date and then told to do an initial rough estimates before pulling in the teams. Until recently the company I work for also did things in a similar way. We are supposed to be an Agile company but that is not Agile methodology. We’ve now changed direction and only “propose” a release date and no estimating is done without SMEs. If they are not available then estimates are only done if the project is similar to a past projects (OPA reports) and the managers know what the development time was on them.

    • In the past I have been tasked with doing quarterly data quality reviews of providers in our Registry. This can be a very time consuming process. When asked about how long it would take me to do this, I would often find myself mentally breaking down the process into different steps. Looking back I can see that what I was doing was trying to make a mental WBS. If a question like that is put to me again I think I’ll probably use a WBS to get a better sense of what needs to be done, and how long it will take.

    • I’ve done some estimates if certain resources are on the critical path for the sprint based on # stories they have and time estimate, they may depend on somebody else stories or may be others be dependent on them. There is a way you can determine what time take individual tasks based on prior similar task complete, but its tough to determine if the resource will be able to complete all his tasks because there are things which are coming from the outside like production support and bugs from previous release sprints. You need the input from the resource as well because he may see things you are not seeing to do better planing of the critical path.

      • I agree with you that a “cushion” is always needed when doing estimates. Also, in project management there is something called Enterprise Environment Factors (EEFs). These are things that may impact a project from an “external” standpoint (i.e. government policy) and needs to be factored into the estimates. Sometimes they can even drive the estimates.

      • Hi Bisser, you bring up a good point with saying that stories or projects can be dependent on each other to be completed. This can make estimating time more difficult especially if there is a large team each working on their own stories. Because of this complexity, sometimes it can help to go with an iterative sprint approach where if something is not ready for the upcoming sprint it simply goes in on the next sprint. This may not work with high urgency projects, but may help with normal fixes or improvements that are going in.

      • Hello Bisser, nice point in taking into account external factors which could potentially influence the finish date for an estimate. I have found out from my work experience that these type of issue normally throw a project off course no matter how much planning you do. It takes team work to come up with a solid estimate on a completion date for a project.

    • The accuracy of the estimates is very dependent on external conditions as well. To be the most accurate your estimate you have to assume the you won’t have any interruption from external factors. So the assumption is you have zero interruption than you need a safety margin 20 more time at least than what you expect, because things may happen miss this or that.

    • The accuracy of the estimates is very dependent on external conditions as well. To be the most accurate your estimate you have to assume the you won’t have any interruption from external factors. So the assumption is you have zero interruption than you need a safety margin 20% more time at least than what you expect, because things may happen miss this or that.

      • Bisser-This is something I need to improve upon. I’m learning that I need that safety margin but am not sure how to know how much of the safety margin is enough to allow for any outside factors that would extend the time I’ve committed to completing the project. It is also not practical for me to set aside 6 hours a day in case I need to get something done I was not able to finish in my previously estimated time.

      • Bisser – I completely agree that it is important to plan for interruption from external factors. However, I am curious how you came up with the 20% figure. I always seem to vary in my estimation of how much extra time I will need, depending on how busy the timing is otherwise and how difficult the project is.

      • Bisser, I also agree to your point that the external factors come into play while outlining the estimates. While dealing with the application issues in my prior job, there were times when I had to bring all the relevant parties on board which included vendors and other internal teams. Often I kept a backup session/meeting in addition to the scheduled one and also calculated the additional time that may be required to resolve the issue based on the urgency and criticality of the problem at hand. However, as Lauren mentioned, even I would like to understand the thought behind 20% safety margin that you have stated.

    • I agree with you. When I first started studying for the PMP and learned about the WBS I realized I did this process even as a clinician at the patient bedside. I listed out the tasks that I had to do with the patient and prioritized them based on highest importance for patient survival.

    • In providing estimates, I usually convert the time needed to Full Time Equivalency (FTE). For example, if I need .75 hours of Analyst work for every 3 hours of Coordinator work then I need a .25 Analyst FTE given every Coordinator’s 40 hour work week (i.e 5 Coordinators requires 1.25 Analyst). Average salaries for Coordinators and Analysts can easily be applied as well. In the hospital world, “productivity” is measured closely at the bedside and that scrutiny is applied to overhead endeavors as well. I once measured what it costs for paper forms to be submitted when an electronic process flow was available. Based on an estimate that each of the four required signees took 1 minute to review and execute a form, it was determined that it cost the organization

      1 minute * 150 forms per pay period * 26 pay periods + 3900 minutes/60 = 65 hours/2080 hours = .03 FTE per signee or .125 FTE given 4 signees. These may seem relatively low but given the salary levels of the signees, the dollar amounts are unacceptable as well given the existence and proven capability of the electronic process.

    • Swetha, I agree that the PM’s job is to ensure capability but I know first hand, as you likely do as well, that not all team members are equally qualified or adept. In the perfect world, those not meeting or exceeding standards are released but we know that is not true universally. When I derive estimates ( as noted in my post), I stick with averages as a way to narrow my confidence level. I have to assume that the manager with oversight responsibility sees to it that the work is done. In some cases when it is evidently clear and more narrow estimate is required, I know the “go to” folks and estimate based on their known productivity level.

      • Maria-
        I agree, not all members of a team take the same amount of time to complete a project or a task making estimates difficult. Personally, there are some tasks that I speed through where some people would take days I can complete in hours. There are other tasks, however, that require more time because they are more detailed task and issues typically come up that have to be addressed. The issue is that some managers assume all tasks require the same about of time because they only think about the person’s individual capabilities completing it, not the task or potential problems themselves that may go beyond the scope of the estimates.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?

      I actually am terrible at estimating the amount of time it will take to complete an assignment or project. I typically look at the assignment and the due date and establish the amount of time I think it will take. I sometimes only allow for a small window of time before I start looking at the requirements for the assignment and figure out I need extra time for team collaboration, readings or searching for resources. My issue is that I make my confidence interval too narrow. I’ve been learning to look at the scope of the assignment or project earlier to have time to plan when I can work on and factor in extra time needed as a buffer to complete. What is a barrier for me is that I typically work on something in one long sitting. It is difficult for me to break a project or assignment up into multiple sessions which explains my narrow confidence interval. If I devoted small amounts of time over a longer time span that would work out, but if I continue to have my one sitting approach, then I have to establish a time frame that allows for all the work that needs to be completed, the prep work and also any breaks I may take.

    • John, I also worked on quality improvement looking at data, specifically for the purpose of reporting outcomes to funding sources. This indeed takes a great deal of time and you’re often on a tight deadline. At my old job, I was looking at a report and the data and the performance indicators did not make sense. I spent a great deal of time trying to break it down to understand where the problem was so I could create an accurate report, but the deadline was more important to my supervisor than the quality of the work. I agree that planning is necessary and often projects take more time than anticipated if issues arise that could not have been predicted, but sometimes at the end of the day, delivering on time whether the scope of the project is compromised, is what takes priority.

    • Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!
      In one of my last jobs I was tasked with a number of responsibilities that needed to get done each day but there was not enough time to complete all of them. I was a social worker on an inpatient unit. I had to conduct psycho-social assessments on patients within 48 hours of their admission, I have to obtain clinical reports from all 4 physicians during their rounds and I had to contact managed care for each client requiring approval for extended stay as well as document everything I had worked on and the outcomes in the patient chart. Since health insurance providers are only available between normal business hours and I was the only person who did my job I had to be smart with my time and focus on the tasks that absolutely needed to be done. My critical path included only sitting to listen for clinical updates on the patients that were due that day and begin calling managed care right away to leave a message leaving time for them to call me back. While I waited I met with doctors and nurses individually to get clinical information I may have missed from doctor’s rounds. Then I checked the EMR to get the rest of the medical information I needed. By this time, managed care would be returning my calls and I was able to provide medical updates on the patients. If I had obtained all of my clinical info and I was waiting to hear back from managed care, I would then conduct my psycho-social assessments for the day. I focused on the tasks that had to be done that day and so I was able to get all of my work done.

    • Sid, this sounds like a huge undertaking, especially when you were new to the company and their processes! I’m guessing there were a lot of moving parts and one seemingly minor change on one component had a lot of affects down the line and on other aspects. An example like this really shows how important slack time is. This example shows how slack time is not only important when a process is not running according to plan, but when the plan was not estimated correctly.

      • Yes Lauren. It was challenging also because these other teams were not on the same site as I was. What really worked in my favor was that at that point in time, there was not much being done keeping everybody in sync. So in a way, I got to start afresh, and set processes which would help the teams work in a more consistent manner.

    • Rikki – Since you were the only one with your role I’m guessing you needed to figure out the critical path on your own, through trial and error. It sounds like you found a rhythm that worked for not only your needs but everyone else’s as well. However, I can only imagine being new in the role and trying to get a handle on all the tasks and ending up calling managed care too late or having missing information. It sounds like this critical path would have taken some time to figure out!

    • Maria – this seems like a really good way to evaluate the capability. The numbers on their own may not seem like a big deal but once the FTE is calculated it really sheds light on the whole process and sheds like on efficiency, or the lack thereof, for a full pay period. I hope the hospital recognized the room for improvement and made some changes!

    • While working at one of my part-time jobs here at Temple, I was assigned the role of Project Manager where the project revolved around identifying technological solution to eradicate obesity in teens. The various tasks that were involved but were not limited to conducting interviews and surveys, engaging in design thinking with team to outline wearables, products evaluation, self-daily monitoring, and journey maps. The team I worked with comprised of high school students, technical architect, and a designer. While outlining the project plan, I took into consideration the estimates for each of these tasks keeping in mind that students had limited time apart from school. Additionally, I had to also think about the availability of the technical architect and the designer as they worked on multiple projects. So taking into account all of these variables and also the slack time around these aspects I outlined the plan for the project.

      • Hello Rishabh:
        Nice mix of stakeholders for this project. How did you go about estimating how punctual high school students were for the various tasks compared to the adults like the Architect and Designer?
        I can see it must have been challenging to figure out the right amount of slack time for various tasks. Was there an app for this or was it a cloud based application?

      • Sounds like a lot had to be done with not as much help or time. Did you face any difficulties while being the project manager? Especially with the high school students since they go to school too was it hard to manage their timings for the work to be done?

    • Hey Rikki – since you were the only person who was responsible for those tasks, how did you manage your time when there was a delay in the critical path? Looks like you had a pretty short turn around time – 48 hours, before you had to get to the next set of tasks. I believe there were a lot of factors that were not under your control and that had to fall perfectly in place for you to keep up.

    • Hi Rishabh, looks like you had limited resources and time – that is two factors in the triple constraint. Were you given a deadline to deliver the project, and how did you balance that with the available resources?

      • Swetha, there was a initial timeline set considering all the mentioned factors and also the two critical resources – designer and technical architect were made aware that they would be required for the project the following week. So they managed their assignments accordingly. However, later the technical architect left the job and the timelines were then massaged to incorporate the leftover tasks.

    • In my previous position I utilized the idea of “critical path” when placing my equipment rental orders for events. After figuring out all the event details and what rental items I needed I typically placed orders with two different external vendors (each carried different types of items). One vendor typically got back to me with an invoice within 48 hours and the other typically had a 72 hour turnaround. Once I received the order invoice I always checked the document line by line to ensure I was getting what I needed. It was too easy for me to forget something on the list that I emailed to a vendor or for a vendor to make an error on their end. About 25% of the time there was an error so the double check was necessary. I made sure to place my orders early to ensure there was sufficient time for changes to be communicated and carried out, before receiving an updated invoice. During busy times it was common that a vendor did not have enough of an item to complete an order, which required a phone call about alternatives and added additional time to the turnaround. It was necessary to have the final invoice amount for the client’s final invoice, which was sent a week before an event. However, while I was waiting for final invoice from vendors I was able to carry about other processes related to finalizing event documents. I learned that it was most efficient to build my rental order lists while I was going through preliminary event details and then send my list to vendors before finishing the other activities. If needed, I could always add an addendum to either order. This way, I received the orders from external vendors with time to spare. All other processes were internal and had a much quicker turnaround.

      • Lauren, looks like you also had to use estimation in times when the vendor had to relook into his inventory that he had missed the first time. How did you manage to estimate the time for that? Also, the critical path was the vendor who took 72 hours for a turnaround. But how did you ensure that the other vendor delivered things on time? Also, any more delay by the vendor with 72 hours turnaround time would mean a mess. Were you able to manage that well? How challenging was that?

      • Lauren, I used a similar process when I was working on magazine publication. I would stagger writing and editing stories so that I could send the art director a few stories at a time and spend time writing and editing the others while the art director worked on the completed stories. Even when there was a backup in the art department, we had a constant stream of work and little lag time.

      • Lauren, this reminds me a lot of my work experience. When planning ahead for events, I also found that ordering items and accounting for possible issues with those orders took the longest time and had to be done up front. Other internal tasks as you mentioned took significantly less time and therefore had a good deal more slack time in which to complete them.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?

      I first try to break down the project into smaller tasks similar to a work breakdown structure, and then estimate the time for each task since it is easier to estimate smaller pieces than the whole thing at once. I also try to take into account any potential setbacks, challenges, or unexpected events that may come up and work that into the estimate. To narrow the confidence interval I can look to see if this is a project I’ve done before or have done something like it. Then see how long the previous project took to get a baseline of how long it might take. If it were a project I have no prior experience with, I would look to see how long it took others to complete something similar. An example would be when I worked on IT support tickets. After doing it for a while, I was able to come up with my average number of tickets completed per day and average time it took to complete one ticket which gave a pretty narrow high confidence interval. On the other hand, a project I’m working on now involves developing a script to track our code deployments. The script needs to be written in Jython, with which I don’t have any experience. In this case I would have a wider low confidence interval since I’m unfamiliar with it. I would estimate that it would take longer than normal because I anticipate there will be some setbacks.

    • I do the same thing in terms of a “mental WBS”. I try to get down to the smallest unit of work I can and then multiply that out for the whole task. While it isn’t always that cut and dry, it can at least give a general ballpark estimate to start out with.

    • Hi Rikki, I agree that it is a challenge to find a balance of allowing enough time to complete a project while being realistic in terms of how, much time you actually have to set aside for it. For me it usually doesn’t go as I planned it (sometimes due to procrastination), but I somehow figure out a way to get it done.

    • Hi Maria, I think that your example shows a good way to quantify productivity in terms of numbers. At my job our 40 hour work week is split up into percentages based on what we are working on. They do this since departments are charged for the amount of hours spent working on their related projects. However, in reality my actual work week never matches up to my allocated percentages since we often get pulled into various things that aren’t planned.

    • Wow Rikki that sounds tedious. Looks like there were many factors that were not under your control. How did you manage your time in that scenario? How did you estimate which part of the process will take how long? Were there times, where you could not finish a certain task, and that led you to miss the deadline for another task, due to rollover?

    • Jonathan, one question keeps coming back to my mind. Looking at WBS, one breaks down a project into smaller tasks. In times of stringent project deadlines, does it not make sense to work in reverse- we get the deadline from the client, and then work with various stakeholders in the team to figure how much time each one of them would want to complete their respective tasks? I think in some cases, this would lead to a more efficient team, and would help complete the project on time as well. I’d also like to hear Prof. Flanagan’s views on this.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?
      In my role as a Clinical Document Improvement Specialist; there are reports generated by revenue cycle which tell us how each specialty service for example, surgical services, is doing as far as documenting appropriate diagnoses for treatment given in the hospital. I review random charts of selected patients daily, based on a daily in-house report. The report indicates whether or not diagnoses is documented. I can estimate whether or not, the report is correct by reviewing the patient charts. My confidence interval is usually wide. I have been training doctors by rounding with them on the patient units, giving feedback, at the time of documentation and giving them monthly training sessions. I can see that there is a more narrow confidence interval when I continue to monitor the charts daily, after the training sessions and one on one discussions in person or via email.

      • Hi Susan,

        Would you agree that these reports are help in improving the time and documentation done by providers? Do they see your rounding and training as valuable? I’ve supported go-lives where I’ve observed workers as yourself come in to address charting corrections to providers and most providers are not happy with those discussions.

    • Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!
      Running the production cycle of a magazine involved finding a critical path to the print deadline. When I first started, I adopted the system of the person previously in my role and found several steps with idle time. For example, after a story was edited and ready for art, the production editor (me) would place the story in a red folder with a label indicating the InDesign file name and page numbers and then place it on the desk of the art director as an indication that the pages were ready to be laid out. The idea was that the art director would lay out the folders in the order he/she received the folders. The problem was that many other publications at the company used email to send changes and instructions, so the art directors would check those first and make them. Another problem with the folder system was that art directors would often have questions about the document or handwritten instructions, which would further hold up the process. After a few cycles of barely making the print deadline, I started emailing detailed instructions to the art directors. They were able to reply quickly with questions and work on the documents earlier in the process. Removing the red folder step saved a lot of time and removed an unnecessary step.

    • Rikki
      Your way is not incorrect. It is a different way of doing things. The important thing is that you realize there are ways. We all learn things from observation or experience. In your example, i feel that our surroundings and our limitations cause us, to plan differently. Projects flourish due to different views of individuals. It is a daily, ongoing learning experience for all of us. No one knows everything!

    • Rikki, I find myself taking the one sitting approach as well, but it is largely because I want to put my full attention on a project. For larger projects like a research assignment, I will break it up into sections and complete each of those in one sitting. When assignments at school stack up, I prioritize them by when they are due and how long similar assignments have taken me in the past. I also consider time of day. For example, it may take be 1.5 hours to complete Accounting homework in the morning right after coffee, but 2.5 hours after night class and dinner. Sometimes, my schedule only allows me to complete Accounting late at night so I need to know both time frames.

    • My goodness, Siddesh, sounds like a very involved project. Too much happening at once. This would definitely have to be planned out on a chart. The time frame could be infinite if there was no format or critical path. What was the time frame of this project? I cannot imagine the amount of discrepancies and misunderstandings on this project!

    • Jonathan, I feel the same way. I can estimate with a narrower confidence interval, if I am well versed on the subject. If I have no clue about what is happening, then I would have a very wide confidence interval. Experience gives us the ability to quantify, quality of projects.
      Education and experience are key factors in narrowing our confidence interval.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?
      I had to give time estimates to clients when we began new projects. I would use a mix of hard deadlines and past experience to estimate the time it would take to complete a project. For a catalog project, I would use the date when the catalog needed to be sent to customers as the hard distribution date and work backwards to identify a start date. Once I had the start and end date, I would use my past experience to set time frames for each step. I would then create two timelines: one for the client that gave me extra days between each step in case anything went wrong and a second one for the internal team with earlier dates in the hopes that we would pleasantly surprise the client by completing the project early. I was able to narrow my confidence internal with more experience as I recognized different types of clients. For example, some clients needed constant communication and review of our materials, which added time between each step. Others only looked at the final product, which allowed us to complete internal steps more quickly but could add time on the back end. Identifying the type of client allowed me to plan when I would need extra time.

    • Hi Colleen – I like your idea of having two timelines, one for the client and one for the internal team. I used a similar tactic in my previous job. I would have a schedule for the upper management, which included slack time and another schedule that had fewer slack time.

    • Hi Colleen – I agree that it can be very challenging to move a task when there is a lot of back and forth. By eliminating the task that took the maximum time on the critical path, you quickened the entire process. You replaced it with emails – which facilitated quicker response time.

    • Colleen, the situation that you have narrated reminds me of a time when I got stuck at the New York airport. Not sure what the issue was that day but immigration people were randomly picking students (mostly) and doing random checks on the validity of the official documents. As part of this process the people were taken into a separate room where they were validated one person at a time. Each of the passports for these people went into a file and was kept in the order in which they were received. Although there were three people processing the passports, there were delays as well in the process. The delays primarily occurred as the officials had to answer the calls they received for a particular case that was put on hold for further inquiry and sometimes an airport staff might come to advocate for a particular individual which was way behind in the pile. Clearly, the process could have been made more efficient which would have allowed the passengers to board their next flight on time and also for others to leave the airport early.

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?
      The best example that I can think of from my work experience for giving estimates of how long it will take to get a task done was when I scheduled for tournaments. A typical tournament can be broken down into 3 stages: prep work, the actual event, and clean up. The method that I would use to narrow my confidence interval was to look back on past experiences and use those to plan accordingly. If I had kept more exact data from past tournaments I would have been able to give more exact estimates, but I would typically round to the half hour. Of course their is always the chance that something will go wrong so you need to account for buffer time. Estimates would change depending on the size of the field, the amount of staff, how involved the event was, and several other factors.

    • Colleen, glad you found a way around. I had a very different experience while I was working for an advertising agency. The agency was very quick to execute the tasks, but the client look a lot of time to get back with approvals. For instance, if we pitched an idea to the General Manager, he would seek inputs and changes from all stakeholders possible. This would lead to the approval time to go up from a day to a week or even more. Quite a few of our projects used to be delayed due to this, as execution would start late, or approvals in between the execution would take time. It was really hard to estimate how long the project would take. Most of the time, we would end up waiting for the client’s approval, or switch between accounts to avoid downtime.

      • Hi Sid,
        I met the same problem while I worked in TV station for government event planning before. Even though the team was efficient to execute or revise the tasks, our counterparts in government took time to integrate their ideas for feedback. The team eventually figured out that sometimes our clients could not even address their need precisely. In order to improve the situation, besides the formal proposal for clients, the team would also provide the designs in the past for other government department as the samples. We also conducted schedule check in every two days and sent out the progress document for every party involved. After the approach, the team reduced the rate of delay.

    • Jonathan, I too agree with your point of knowing about something enables to narrow the confidence interval. When I worked with consumer management company, I had to utilize Tableau tool in my day to day duties. I had limited knowledge of it initially as part of which I had a wider confidence internal in order to complete the tasks that I was assigned with. However, as I got more familiar with the tool the confidence interval narrowed down for me.

    • Project to Scaleup Preclinical Drug Candidate
      Contract with CRO in Hydrabad, India
      Project
      15 Step Synthesis, 5 FTE’s includung a project manager in Hydrabad.
      Procedures Validated in Boston
      Tech transfer to Hydrabad from Boston

      Procurements:
      Reagents
      Sourced in India
      Backup Supplier in US
      Solvents
      Sourced in India
      Backup Supplier in EU
      Standards
      Sourced in India
      Backup Supplier in US
      Consumables
      Sourced in India 100%

      Custom Building Block(1 kilo of crystaline powder) sent to India
      Customs Building Block clearance into India

      Customs Clearance into US
      Quality Assurance Checks in Boston
      Shipping Final Drug Candidate 1 kilo

      Duration 60 days

      Project Plan draw on a white board in Boston Office
      Ciritcal path dtm 25 days for Synthesis of Custom Building Block in Indiana Site.
      Shipped to Boston for QA and then to Hydrabad.
      Project meetings Daily or as needed via Webex, Skype or Landline calls.
      On call 24 hrs.

    • Rikki, I also at times fall into the trap of not estimating for break times, meals,travel times, and other activities that can detract from my work. I think it is most helpful to really think through the entire process when planning and be honest with yourself about how long the total amount of work including breaks etc. will actually take. Hopefully one day I will start to use that line of thinking myself.

      • Oh geez, that’s a good point. I was trying to plan out my school work for this three day weekend and I never even considered taking meals into account. I ended up doing the bulk of my work on a single day, but I probably would have had a better estimate had I considered non-work related activities factoring into my available time.

      • That’s a really good point! We often tend to forget to include the time taken for “unproductive” works which results in inaccurate estimates. Even I do the same thing while estimating the amount of time I would take to finish the assignments. Most of the time, I tend to go beyond the time limit that I have set for myself.

    • Although I was completing a very different set of tasks, I briefly spoke to the effects of set backs in my example as well. I agree that it is much easier to estimate times when you are completely familiar with a task. The difficult part is estimating how long a setback will take because they are at their very nature an unknown event so their is no great way to estimate an unforeseen issue.

    • John, I think that to some degree we all do a “mental WBS”, but don’t actually go through the process of physically writing out all of the steps in the process. This is where people often come out with unrealistic estimates for the time it takes to do a work process or even daily activity. The WBS is something that I would like to start using on a more formal basis with both work and my personal schedule to become more efficient in the use of my time.

    • Hello Thomas, golfing events are interesting because the club gives you a window and there is always a group that just can’t finish on time or play too slow. Does the estimate take into account like how many players attending the event and charge accordingly? I can see that depending on the size of the event one would need more FTEs per crew work on the event and cleanup.
      I agree on adding a buffer as a way to account for unforeseen issues that may surface.

    • Nice job Maria. If we could take your point and apply it to the PHS scenario where an organization is dealing with large volumes of forms and a wide spectrum of employees ranging from highly paid specialty physicians to a general practitioner at the end of the day, paper work adds up a sizable amount of money.

    • I agree, and I think the devil is in the details. When I give an estimate based off of a mental WBS it seems reasonable, but inevitably I run into issues I had considered, because I had not actually mapped it out.

    • While reading the posts on this blog it occurred to me that one time I think we have all attempted to calculate a critical path is for travel. International travel especially is dependent on a person figuring out a critical path. I need to be able to figure out the minimum amount of time it will take me to walk from the terminal in which I land to the terminal where my connecting flight is. If I fail to figure this out the result I miss my flight. Which may not be a big deal when traveling domestically, but can be a huge deal for an international trip.

      • Hi John,
        It is a great example. How to design the route in the trip is very crucial especially while you travel in countries with complex transportation system, such as Japan. Take the Tokyo city as an example, there are at least 5 different routes in subway systems that you can utilize for traveling from Shinjuku to Tokyo Disney land. The price and time of the routes sometimes have huge differences. As the result, Yahoo! Japan provides the route design platform in their search engine to help tourists to identify the options among cost-and time-saving. It also offers the related information of the destination and recommendation for visiting. The tool is really helpful for determining the critical path for travel schedule while you are not familiar with the country.

      • Hi John, just coming up with this thought and putting it out there, don’t you think that Google maps kind of do the job of PERT. we feed in the requirements and it gives us different paths and estimates and based on the timeline, we chose the critical path. Generally we tend to chose the minimum time as the desired path. It also gives us options, (relating to the skill level or resources available, haha), that we can chose a car, public transport or walk!

        • Perhaps I am misinterpreting critical path, so please clarify:
          I thought a critical path was relevant when there are steps executed simultaneously, and you have to determine the length of the project based on the path that takes the longest- thereby also calculating slack time and efficiency. A lot of these examples seem to be linear processes that have one path- which I suppose could be considered critical.
          I was just wondering if there was a distinction, or if the critical path is relevant in a single linear process (ie a>b>c vs. a>c; b>c)

    • 1.Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!
      While I conducted marketing campaign including physical conference or event, the team mostly would use backward planning for time management. After confirming the scope of work, event location and date, the team would draw out the schedule and identify the possible critical paths based on the experience in the past. Take new branches opening event for example. The most time-consuming and uncertain procedure would be producing the print materials and event souvenirs. Because the procedure includes internal image design and production outsourcing in China, we usually added extra 1 or 2 weeks to deal with delivery delay or other urgency. Then according to the time reserved for outsourcing, the company would also identify the internal critical path to allocate the staffs to make sure that we can complete the design and get sample products in the shortest time. The main strategy is to assign all the team members and shift staffs from art design department in brain-storming as well as design stage. Even though in marketing filed, determining the critical path may not be that crucial for cost in one event, the work method is still important to be adopted as the model for time management.

    • 1.Give an example (at home or at work) where you’ve needed to determine the “critical path” to get something done, even if you didn’t use a PERT chart to do it!

      Creating a new EAP (component record) to use as an option for ordering a new medical supply in the system.
      1) Pull the next available procedure record from the build tracker
      2) determine if there is a similar record that exists to mirror the new component after
      3) determine if this order will be orderable, performable, and/or chargeable
      4) will there be any default settings for the order status (normal, future, STAT)
      5) add synonyms for easy search options
      6) submit built to Change Control for approval
      7) get assigned a Change Control # to present new build
      8) present new build at Change Control
      9) Approval given
      10) add new build to import spread sheet
      11) new build gets imported into the Build environment
      12) test new build
      13) request migration of new build into Production

    • 2.When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?
      Personal experience in the past is the first thing that I would examine. Then the internal record is also a good resource to look at. If the company already has particular goal in time or cost, these two resources will set the baseline for me. Additionally, I would also reach out to related stakeholders and generate their opinions. For estimations of project with large scale, I will also consult with third party experts. Even though I can always find information or method online or in some professional social media, I will not take it as main source unless I confirm the materials with reliable resources.

    • Swetha – I really like your approach of “backtracking” in order to estimate the time taken. I believe that breaking down the tasks into micro level helps in understanding the dependencies of the tasks and also identify resources needed. As Rikki had mentioned, amount of time taken varies per individual depending on their skills and comfort level in working with the task. This makes estimating even more difficult. Having a buffer time is a good idea so that the actual time taken is not very high from what is estimated. I think experience plays a crucial role for this activity because one can learn to estimate accurately based on what worked and what did not work from past.

    • A personal and recent example of determining the critical path involved a painting project that was to be carried out by my two teenage sons. I embraced this project as a means of helping them learn a skill so i participated very minimally 🙂 Interestingly, the older son wanted to just plunge right in and “get it over with” whereas the younger son intuitively knew there would be a process. As you all likely already know, the most time consuming part of a paint job is in the prep work. Knowing that we were hosting Easter dinner, and that they would be off school Thursday and Friday, I started to help them plan two weeks ago. The PERT chart was of course in my head but I had them write down the tasks and plan accordingly: remove the existing paintings/nails, remove certain furniture pieces, prime walls, spackle/sand holes, and tape woodwork. given schedules, we certainly needed the 2-week prep time! Most of the painting was done by Friday afternoon with just touch-up work needed to be done on Saturday. The job was well done and hopefully they both learned the value of sufficient prep time and prep work.

    • Hi Pei,

      I think these are all good starting points for estimations. Do you think you would find some barriers with the stakeholders, company goals, or cost given to estimate a timeline?

    • When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?

      In my first company, we used to follow the Microsoft tool but customized by my company to provide any estimates for the upcoming project/enhancement/change. All the work was IT software development related, hence over the time the company did evolve with certain standards that helps us be in check and determine the place and the category where the task/job will fall into. Based on the work that used to come in and the requirements associated with the work, we used to determine how critical the work is. Also, based on the requirements we used to have a basic idea that what would be the size of the project. If it was an enhancement, but exceeded the company set standard hours, we would negotiate it to get it as a project rather than an enhancement ticket. If it was a change ticket or project, the requirements and the modules that the change will effect and work involved in the effected module would determine the criticality and the size of the project. Generally the project would of small, medium, large size. The hours would be determined by selecting the type of modules under work and the type of changes or additions to be made in those modules. The hours would also (help/suggest) determine the skill level of the resources and the management people involved. The addition of buffer time was pre set with the amount and the level of work involved. So ideally, there wasn’t much to play around with the timelines and the software usually gave estimates that were “ideally” accurate and the buffer time keeps in within the intervals!

    • Maria, so glad to hear that your sons excelled in the paint job and that it involved PERT methodology 🙂 Also, to see an example thats not work or IT related is so refreshing. You were acting as a manager and your sons as employee and you managed the work and started planning two weeks in advance. Unknowingly, we always follow this approach in our day to day work and i especially do it in planning my vacations (even more enthusiastically!). We plan in advance and start prepping by gathering and accumulating things that we might require. We have a list which can be compared to (requirements) documents. We set a budget aside for the vacation and things involved in that. And after the vacation , we set up an album (similar to user manual)

    • I had to create a timeline for aggregating data related to a certification proposal I am working on. The timeline was based on my assumptions of how long it should take to collect the relevant data, and on what I was told was readily available information. Needless to say, this method was extremely inaccurate. The model did not take into consideration other high priority projects that the team was working on in conjunction to this project.
      I could have asked for a weekly time commitment from the team that would provide a better context in which to budget time. I could also create soft deadlines for certain deliverables, which would have encouraged the team to keep up with the timeline outlined. However, I am a volunteer working with upper management, so my deadlines would be easily disregarded if other commitments arose.

    • Katty, i like your enthusiastic approach to consult different sources to produce your exact estimate. But don’t you think that all these will be required while you are gathering and eliciting requirements and early information about the project/job. Based on all the information collected and the rescued and infrastructure available, you will be able to determine the estimate and the timeline. Let me know your thoughts in this !

    • Working on group projects requires a consideration of the critical path. Often, our GMBA group delegates duties. Each duty is not equal, and people work at different speeds. In coordinating our internal soft deadlines, we consider whose piece will take the longest and schedule accordingly. Where there is slack time, group members can work on other group projects in attempts to balance out the overall work load.

    • Maria-
      I think this is a great example of time management/project allocation. Can you clarify how you determined the critical path and utilized slack time, if at all? Did you have your sons working on projects simultaneously, each with different time commitments? Or did you work as a group linearly?

    • 1. When you’re asked to give estimates of how to get something done at work, how do you go about doing it? What methods could you employ to “narrow your confidence interval” and provide a more exact estimate?
      At my previous job there was some data entry that I had to do using Microsoft Access for a social group project. I was given pages and pages of information that had to be documented into the Access system. I broke down how many pages I could do on the days and the times I was working so that I had a target of how many to get done each day I was at work.

    • Your response was interesting to read and rather real. I tend to try to get things done in one sitting many times too and that can be tiring and not always so effective, but sometimes one does not have a choice. At times it is better to break up the work in portions so one isn’t overwhelmed and can be more productive too. It is good that you found out what you can do differently to get better results.

    • I agree working on projects with others divides the work and with each person their working speed is different as you state. I have seen this occur in my work place where working together is key to get things done and keep up with the work level for the day.

    • Colleen-
      I think having two timelines is a great idea. Did you experience any conflicts in trying to reconcile two different timelines? Did team members slack off on the internal deadline because they knew they had more time according to the client timeline?

      I think using client types as a way to manage time is also a great idea. It seems a bit hard to quantify, and as you said definitely seems like an experiential endeavor. Do you think establishing more concrete time allocations for client types would have been beneficial, or is it truly an individualistic meter?

    • Pei – I like this example of forcing yourself to at least recognize that there are a series of sequential steps needed to carry out almost anything! My entre into quasi- project management started with the idea of moving backwards and i think this is good practice for business novices so that they can recognize the number and series of steps needed for a particular outcome. This is especially helpful in identifying questionable steps.

    • Pei Yen, confirming the scope and details is an important first step, otherwise you will have many setbacks during the process. Additionally, though planning for delays seems like it would be interfere with the quickest path, it helps in the real world when the unexpected happens. We often did this during print product of the magazine, because sometimes an advertiser was late submitting an ad or we would have a backup in the art department. Building in that extra time allowed us complete projects on time (or early if somehow there were not setbacks).

    • Having two different timelines is a good approach as it would allow some additional time for you incase everything doesn’t work out as planned. In my past experiences, when I had to come up with timelines for a task allocated to me, I first divided the task into subtasks and verified if there are any dependencies on other team to complete the task. In case, I had a dependency, I would make sure to add a few extra hours than what it would actually take to finish the task. For the tasks without dependencies, I used to estimate based on how much time it took in the past.

    • Hi Brinn,
      Good question!
      I did find some barriers especially dealing with stakeholders and cost given. In marketing filed, all the company sponsors hope to gather the largest impact with the lowest cost. When I received a scope of work with short budget or nearly impossible timeline, the best strategy for dealing estimation is to provide another the design with smaller scope along with the original estimation to address the backup plan. As for dealing with stakeholders, it is more about politics in the organization. Sometimes, they did have the skills or knowledge to shorten the timeline. However, they may not want to share because they are afraid to lose their “power” or simply lose their face. I also tried to be careful about not only taking one person’s opinion while I conduct the estimation. Sometimes the stakeholder cannot see the whole pictures and just answer the question from their position.

    • Peggy, I actually had a mental third timeline for myself that was the real timeline (which sounds crazy when I write it), but I knew that many team members did slack off knowing the real timeline so I had to adjust for their behavior. Some team members were reliable regardless of timeline so I would share real dates with them. Much of running production was figuring out personalities and who could have certain information to ensure that the project could be completed in a timely manner without staff issues or other setbacks.

      We had more concrete time allocations based on project types. I would be worried that organizing clients into “types” in a formal matter could be an HR or PR issue for the company, but it could be an interesting exercise.

    • Thats a great example Maria. Outside of my professional work, I went ahead and volunteered for an non-profit organization where I gave a session on India and its culture to children. To ensure that children get enough exposure out the session I started the preparation a week earlier to list out the tasks that I want to do as part of the session. I outlined a presentation and then further divided into different sections which revolved around the customs, dance forms, foods etc while the other task was painting a butterfly. I ensured that I wrapped up the presentation followed by questions on time so that children can get enough time for their paintings. All together it was a nice exposure and my preparation helped to deliver what I had planned.

  • Leave your response as a comment on this post by the beginning of class next week as well as your comments on your peer’s responses. Remember, you need to average four posts a week for a B. For these wee […]

    • Give an example of a project on which you’ve worked (either professionally or otherwise) where you’ve had to make a tradeoff between time, scope, and cost. What factors affected your choice?

      One of the examples I can think of is this video app I was working on at my last job. It was supposed to be the principal product for the organization, and was supposed to house all the premium content that was produced over the years. Initially the scope of the project was defined well, and a timeline was set. Going forward, other stakeholders got involved and different opinions started floating around. Then, because the app was supposed to go on the Play Store and the App Store, the team got in touch with people from Google and Apple as well. Their involvement led to the scope getting extended. One of our partners was supposed to launch a new virtual reality technology, and offered to give us early access to it for the app. That added even more to the scope. With the scope being extended way more than what was initially decided, the timeline was bound to be missed. The app finally launched 2 months later than scheduled and the cost had gone beyond what was initially budgeted. The upside of this was that the new technology combined with the premium content we were offering helped us get a lot of media attention, and pulled in a lot of partners who wanted the app on their platform, and were happy to co-fund the development for their respective platforms. I believe that the distribution of the app on various platforms helped us decide if it was really a risk worth taking if the app launch was to be delayed. We finally got the app on Windows 8.1, Amazon, Windows Phone, BB10 etc.

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?

      Although hiring the wrong people on the project is the worst one can do to the project, I believe not keeping oneself up-to-date with the status of the project and also not tracking changes to the project could be disastrous. I think it is absolutely critical to make sure that every minute change is being tracked and logged. I have been a part of a project where the vendors were not really tracking every change that was being suggested and were working in their own space. Because of this, the log at my end ended up differently than what was at theirs. This also led to the project deadline getting extended and double the work for the vendors. I was working on around 68 products which were a part of the same project with the same vendor. Although it was difficult to track what was happening in all areas, I kept a log of what was being discussed over every call. On the other side, the vendor which had 2 different project managers failed to keep a log of all changes that were being discussed. We spent way too much time reiterating what was discussed previously. It was probably one of the worst experiences of managing a project I have had.

      • I am in complete agreement with you. I currently have individuals on my team who count on others and myself to track all the changes, keep meeting minutes and then expect me to update them at their leisure. Teamwork doesn’t work that way and if a single person is left to track the changes, whether they are the project manager or not, if that person should leave suddenly the project would suffer greatly. I make it a point to verbally update everyone and send out meeting minutes but if they do not keep themselves updated then they have to take ownership when their tasks are incomplete.

        • Stanley, I am all for team work as well, no matter what kind of project I am working on: personal or professional.
          Some people cannot work in a team, that makes it difficult for others in the team as we all know. It takes a special talent to be able to work in a team environment. I can lead and i can also work in a team. I wind up taking the un-named team leader role in many instances just to get the individuals in the team to move in a timely fashion on their portion of the project. It is definitely a stressor but I seem to wind up in teams like this more than teams which work well together. I feel that some of that is built into our self-discipline.

      • I think the vendor was also not communicating well in addition to not keeping track of the changes, which ended up having more time being spent discussing the discrepancies in the changes. I agree that if changes are not carefully tracked then something could end up in the final product that wasn’t meant to be there which could adversely affect the functionality.

      • Sid, your example sounds like a variation of the dreaded meeting where no one takes notes, communicates to others, or does any follow up activities after the meeting. Everything discussed ends up having to be re-iterated at a later time and the meeting ends up being a complete waste of time for everyone involved. I agree that it is necessary to take detailed notes because it is impossible to keep track of all the details otherwise. This is especially true when it is necessary to reference the meeting or project weeks or even months later, like you explained.

        • Oh communication, so important, but no one ever remembers to communicate that to any one. I once had a supervisor who, upon taking control of the program made it a point to tell us how no one in our department communicated with one another. After which she made it a point to never communicate with us. So when she left we were completely in the dark about what special projects were under way and what grants were due- absolutely maddening.

      • I agree that tracking changes is really important. I’ve worked on projects where changes made were not documented. This caused issues for current team members who were not aware of updates and thus were working in the wrong direction or working on things that may no longer necessary. This also caused problems for team members who came on board after certain team members had left. The changes and new information that was obtained about a project or client left with the old employees so new employees had no idea what was going on or what had been done prior making it difficult to proceed.

    • Give an example of a project on which you’ve worked (either professionally or otherwise) where you’ve had to make a tradeoff between time, scope, and cost. What factors affected your choice?

      I once took in charge of the opening event for the new branch of fashion retailer in Shanghai. Because it was the first time that the company launched the business to China, we did not have lots connections for event support. Even though we booked the open deck where has the capacity of 300 people in the same department store that the branch located in advance, the reservation was cancelled by administration of the department store for other promotion event of local company 3 days before the launch. The team was forced to make the choice between pushing back the opening in order to match the original design as well as event scope in same location and reducing the event scope, changing the setting in smaller location nearby and making the opening on time.
      After discussion, I decided to cut the scope. First is because we already sent out all the invitations for the local press. We did not want to leave bad impression to them particularly in first launch. Second is due to the budget control. By holding the event on the same day, we were able to get full location compensation from department store. The saving could be move to pay the extra expenses from the issue. Additionally, company sent out a team of 6 people for the opening from Taiwan. Pushing back the event means the company needed to spend more in hotel and traveling. In the end, the team quickly handled the related changing, managed the event within the budgets, and completed the goal to attract enough local media and new customers in the first day opening.

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?

      Even though projects that lack the right resources with the right skills is the most important mistake that I believe the organization needs to avoid, I would like to share my thought on another crucial mistake: Project team does not communicate well with project sponsors and stakeholders.
      The potential impacts of the mistake are failing to deliver the expected requirements, waste of recourse, time and human capitals, harming relationship among departments as well as stakeholders and demotivating.
      Take my previous company as an example. The company once tried to upgrade the CRM system to include the new business service into the analysis. The IT department and project manager did not put much time on communicating with related stakeholders, such as sales representatives, and project sponsors (our GM and CEO). Although the company indeed hold several cross-department meetings to identify the needs, it turned out that IT department, sales department and project sponsors all have their own interpretations for the topics decided in the discussion.
      When we ran first testing for upgrading, most stakeholders were not happy with the system and started to blame one another for misunderstanding. The blames also hurt the morale of IT department. To solve the problem, company assigned the new project manager who is familiar with both front line and support operation in the company and conducted series interviews with end users, strategy analyst and project sponsors. Additionally, the team also reported the process and mini-tests in week base. In the end, company spent twice as much time as they anticipated to complete the project.

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?

      One of the most common mistakes in projects is that problems are ignored or allowed to fester until they become even bigger problems. There are a variety of reasons why they are ignored. Sometimes the group thinks it’s minor so it does not have the priority of other things or it could be that the person who made the mistake does not want to come forth to identify it. When the problem is identified late in the development cycle it could become a blocking issue and push the timeline out further. This is something that occurred recently with my current project and now we need to wait several days for a new software build to have the fix unit tested before we can continue integration testing.

    • Normally when scope changes there is a tradeoff with other requirements to try to keep a project within the budget and timeline. Was any discussion made around descoping other requirements before they increased the timeline and the budget? When the company I currently work for gets into these similar situations we will try to descope and if that doesn’t work we move to possibly release the product or service on time but provide a service pack enhancement soon after.

      • Stanley, we were in a dilemma if we wanted the product release as scheduled, or a better product that would be released later. The budget did take a hit, but we were able to recover well as the new technology helped us reach more platforms, and thus produced more opportunities to generate revenue.

    • Sounds like all your changes allowed the event to be held on time and on budget still. This is a nice example of how the tradeoffs between these 3 constraints work when done properly. Nice job!

    • I agree with you. Lack of communication is a huge problem in projects especially if they are large and across domains/teams. It leads to having to re-scope or scope creep and that causes a downward spiraling affect with the things you mentioned in your answer statement. I have to remind myself to never assume someone knows or understands what I’m talking about and to ask questions if I don’t know what they are speaking to. In the end, the client suffers because of communication is poor.

    • In a project I’m involved with currently we had to push back deadlines and increase the time to complete the project, which in turn has increased the cost. The project involves upgrading our message queue infrastructure. The message queues allow different systems to send and receive data to each other. The project was initially started in June 2015 and was scheduled to be completed in November 2015, however due to an issue found during testing we had to back out of the changes. Our company has a freeze period in December and January, which means only emergency changes are allowed to go in so we had to resume the project at the end of January. Another setback happened in January 2016 because due to some miscommunication between teams, the new message queues would not be completed in time to meet the deadline. We then had to back out again and schedule for an April 2016 go live date. Even since then there has been a couple delays with issues found during testing, but they were resolved and we are still on target for our April 2016 go live date. The scope of the project has been consistent throughout, but the costs have increased due to repeatedly pushing the date back. My department doesn’t deal with the cost aspect, which is managed by the Project Managers so I’m not sure on the details of how much the cost went up, but due to the increased hours and extra work involved it is known that the costs went up.

      • Jonathan, that sounds like a complete mess of a project. What I can make of it from this is that the execution was poor, and the team was not able to recover from the issues found during testing at all. I wonder if this was a case of putting the wrong personnel on the project or was the project not managed well. I am happy to have not faced this issue till date, but as John points out, this could be one of the worst mistakes the team can make.

        • I think the issue was the project not being managed well. There are 5 teams involved and at times there was poor coordination. After the two month freeze period the project manager thought that the project was ready for the performance testing environment, which is the environment it goes to right before production. But since the infrastructure team was not engaged they did not know when the new go live date was so they wouldn’t have the new message queues ready in time.

          When it came to my part of the project, I saw I was given the old message queues which was not right. When I reached out to the infrastructure team I saw they weren’t included in our weekly meetings. I then invited him to the meeting and we then realized what the issue was but it was too late to fix without pushing back the deadline. So yeah the project was a mess 🙂

      • Jonathan. This sounds like an issue I believe many organizations face. When departments are isolated from one another, the impact of work of one department isn’t seen in other departments. When I worked in performance improvement I was supposed to make recommendations for improving care based on trends and opportunities I saw in the data. I had no access to financials. I had no access to the financials to see the implications of the problems I was identifying to know if my recommendations saved money or cost more or how it impacted the scope of treatment. This made decision making very difficult.

      • Hello Jonathan:
        I have to agree with poor execution but it sounds there is more than poor communication at cause in your example. I am wondering how the project change control was documented in the project plan. It seems that this could also be an issue otherwise the Jan 2016 setback would have not occurred. Good luck on going live on time.

    • I think you made the right decision in this situation. Pushing back the deadline would have caused even more problems and further increased the costs. Even if the scope was reduced, the project still sounds like it was a success. When these unexpected things come up I think it’s best to look for a solution that can best mitigate the negative impacts.

    • I’ve also seen times when small problems can snowball into something much bigger. In my job we have been getting alerts every day for an error message that’s occurring on our website when searching for a doctor. Right now the impact seems to be small since it’s a temporary error that is resolved by just trying the search again so we haven’t received any complaints. However, we are still looking into the error further cause it could have a larger underlying cause. Granted this hasn’t been made a top priority and has been put on the back-burner so as you said there is the risk that it can blow up into something much larger.

    • I have to say, I think the biggest mistake you can make is picking the wrong personnel for a project. I have seen some pretty poor choice for staff affect our every day operations in a major ways. I’d have to imagine that in a project even with the right amount of resources, if you pick the wrong personnel for a project it is doomed to fail.

    • Hey Pei Yen, great example. But I am curious to know if cutting down the scope of the project had any major impacts on the project? I understand that the event went well, but was there any measurable impact that you think could have been avoided if you did not have to cut down the scope?

      • Good question, Sid! To be honest, as the project leader,, I was happy that we reduced the scope of work at the time. Because the company did not build any connection for event support. It took us some times to understand the environment difference between Taiwan and China. Take part time staffs as an example. In Taiwan, we can easily hire some event agencies to recruit and train the one day part-time staffs for particular event and we hardly need to monitor them. The project team can focus on dealing with more important guests and project flow. However, in China, it was totally different. At the time, we were forced to recruit and train the part-time staffs by ourselves. In addition, we quickly found out that employees in China need more micro-management to make sure they execute the task in the right way. The main purpose of the opening event is to build brand awareness and relationship with local media then with end customers. While we decided to reduce the project scope, we did not cut down the number of media that we invited. We simply cut down the number of free walk-in for the end customers at the day. At the same time, I was also able to cut down the part-time staffs that I need to hire and manage in the event. It is actually hard for me to say that we would have better quality or result for this event if we had executed it with original design.

    • Haha! Worst mistake ever. I have been a part of a project where our team did not keep the all the stakeholders involved in the changes that were happening rapidly at that point in time. It was quite an intense experience, where rollbacks had to be made, shipments had to be stopped and partners had to suffer. Although the issue was sorted a couple of days later, the experience caused a lot of trouble and stress to all parties involved.

    • I think the vendor did not really have the capability to handle a project of such scale. Not only was external communication poor, but even internal communication between the vendor teams was not up to the mark. Also having different product managers communicating with me, and not sharing information with each other was a complete disaster.

    • I think that “Mistake No. 10: They don’t consider Murphy’s Law” can be a incredibly detrimental in any project. In my last position I quickly learned that it was necessary to stay a few days (ideally a week) ahead of schedule in order to have adequate time to deal with any surprises and keep the surprises from negatively affecting other moving parts of the business. I planned for surprises to happen because they consistently did happen and I wanted to negate the unnecessary stress and pinch for time associated with them. I think it is imperative that one does not plan for the stars to align but rather plans for a few roadblocks along the way and pads the timeline accordingly.

      • I agree with you, Lauren. Some concept should also be considered in budget allocation. During my experience in marketing field, I always tried to take 5-10% of the budget off before I decide the budget allocation. The way help me dealing the urgent accidents while the team could not easily change time or project scope. Additionally, if we are lucky to have a smooth project (which is nearly impossible), we would be able to earn extra profits.

      • Lauren, its an important point that you have highlighted. While working in support and maintenance projects where there were over 40 applications distributed among four people, it was quite important that there should be some overlap in terms of the knowledge about handling these applications. So that if anyone is unavailable due to some unavoidable circumstances, then the other person can jump in and perform the necessary task. Since, in absence of such a structure the issues might not get resolved and it could result in paying a penalty to the client.

      • Lauren, I tried to do the same with print production cycles. Sometimes (rarely), we would finish early, but we usually needed the extra time. When we did not have the extra time, we would have to push back our print dates, which cut into profits. Ignoring Murphy’s Law could spiral into a loss for the quarter and so forth, so adding that extra time to the schedule is imperative.

      • In my experience I can definitely say that Murphy’s Law is a real thing and that people often fail to account for it in planning. Anything thing that can go wrong, will go wrong. I think a good example of this from our our everyday lives is the friend who is habitually late. In the mind of this person everything goes off without a hitch. They will leave their house, it then takes exactly 30 minutes to get to the store, they will be in the store for 10 minutes, then meet you for dinner around the corner as scheduled. What actually happens is they hit traffic on the way to the store, the lines are long at the store and they have trouble finding what they want and next thing you know they’re 20 minutes late. Trouble almost always arises and it is very important to deal account for it in your planning. In the rare event that you don’t hit any speed bumps along the way then you’ve completed your task early and that is a good thing.

    • John, I agree that staff are incredibly important as I have seen a seemingly simple project fail because of inadequate resources. However, I do think that with proper training this problem can be fixed. I know that in a fast paced environment it is difficult to find the time to mentor / train / explain improvements to team members but I have also seen complete turnarounds when a team member is given the proper knowledge.

      • Lauren,

        I think training helps, but ultimately it comes down to the individual. If they are unmotivated or unwilling to bend then all the training in the world won’t help them. When selecting staff I think it’s important to understand not only the skills of the individual, but their personalities as well. Like in the CGI study, they opted to choose a team of programmers who were not as experienced as their senior level staff but were very motivated to learn and complete the project. The team realized that their inexperience in this case was an advantage because it motivated the junior programmers, who were eager to learn a new language.

    • It sounds like simply summarizing the scope and goals and asking the project sponsors and stakeholders for confirmation in the beginning of the project and along the way would have fixed a lot of problems! On several different occasions in class we have eluded to the fact that one concept can easily mean two different things to different people (or probably 10 different things to 10 people) and that is is necessary to get everyone on the same page. I think this is especially true for inter-department projects when team members do not have a clear understanding (or any understanding) of the workings of other departments.

    • As a cook in a professional kitchen, there is almost always a tradeoff between time, scope, and cost. You could provide the least expensive, quickest meal (think fast food), but the scope/quality would be low. Conversely, you could prepare the most extravagant meal ever, but the cost and time would be massive. The key for cooking is to choose how you wish to position your kitchen within the market, and this positioning helps define which tradeoff you are willing to make. Do you want to be a fast food restaurant, or a high end dining experience? In our kitchen, we were mid-cost, mid-scope, mid-time: we weren’t the best at anything, but we were pretty average at everything.

    • I agree, letting a known problem sit unaddressed can be a nightmare. I think it is always good policy to triage the problem, examine it and make you decision based off of what you know.. I have often found that small problems are symptoms of larger ones. It’s like standing in quick sand, suddenly you find yourself in over your head.

    • #7
      When a manager ignores problems, situations can quickly spiral out of control leading to expanding scope, over budget, and over time. Underlying all the other common mistakes is a Manager that ignored some problem- i.e. not considering Murphy’s Law. That is a problem that has been ignored, causing problems further down the line.

    • The mistake I find the most important to avoid would be #7. I find this most important probably because this is what frustrated me most about my past jobs. In my last position, I was trying to complete a task such as analyzing data from a report and was seeing that the data we were collecting wasn’t matching the data requested. This was because the data was already being collected when the project objectives were created and no one checked to see if we were actually collecting the information we said we were measuring. This was the first problem. I then found out that the data was not only wrong, but was also incomplete. Over the years, some sites had changes to their billing system and didn’t understand how to code for services to put into our data warehouse so they had been submitting aggregate monthly data to my predecessor. This was problem number 2. These large problems were ignored for about 2 years and snowballed into a very big problem of our data being completely wrong. When I brought this to my supervisor, she said if we fixed anything, we’d have to explain to our funding sources changes made to our process making our numbers drastically different than years before. She recommended just making my results up so they coincided with previous reporting periods. So ignoring a problem leads to other problems and eventually such a large problem that it takes a substantial amount of time and staff to fix. There is also an added issue of the outcome is inaccurate or wrong making the entire report useless. If problems are addressed as they come up, these large issues down the line can be avoided.

    • Give an example of a project on which you’ve worked (either professionally or otherwise) where you’ve had to make a tradeoff between time, scope, and cost. What factors affected your choice?
      Although I understand people are not necessarily “projects” I had to struggle with these triple constraints when I worked in utilization management. It was my job to get financial coverage for inpatients. The length of stay and cost health insurance was willing to pay for a particular patient depended on their progress in treatment and the doctor’s treatment goals. There were times when patients had insurance coverage only for a few weeks and managed care was strict in the amount they were willing to pay for care. Often times, patients would require more time in the hospital but managed care would deny additional days or financial coverage thus compromising the scope of treatment. This resulted many times in patients relapsing and needing to come back into the hospital which then cost managed care more money than if they would have agreed to pay for the patient to stay longer in the first place.

    • I agree Margaret, you can’t have the high quality food, fast at inexpensive prices. This is an issue I’m currently working on with a CSA client in another class. It took a few months to figure out which trade off they wanted to make. They wanted to grow but did not know if they wanted to compete with price, quality, convenience, variety, etc. They couldn’t offer fresh, high quality produce at prices lower than their competitors on their customer’s door step the next day. Tradeoffs need to be made but first its important to understand which aspect is most important to you in order to identify how you want to compete.

    • It is always best to admit when a mistake occurred or may have occurred. I am lucky to work in an environment where we actually welcome mistakes! Making a mistake is the best way to learn (presuming it’s not a matter of life or death!). We are a learning environment for the most part and often when a mistake is bigger than initially thought, many minds come together to solve the problem as opposed to focusing on the blame. In my limited experience with IT projects, I have found it fascinating how teams come together in support of each other at these times. Therefore, I encourage my staff to be open, honest and forthright about potential mistakes. Likewise, I manage up accordingly and have found my superiors very open to my admissions.

    • Interesting application that is to the food industry! My friend is a food broker (pork, beef and cheeses mainly). Just recently, he was introduced to a cheese “product” that like American cheese, “slices & melts” and that’s all that is required of buyers of American cheese “slice & melt”. Yet, I questioned whether the “product” would sell given that it wasn’t real cheese. He explained that the “product” can be sold as such as long as it meets same nutritional standards as “cheese”. From a taste perspective, it is the same. Meeting the nutritional and taste standards was the easier part for cheese makers but nailing the “slicing & melting” was the hard part but they have succeeded. So, now the cost has been reduced yet the scope and time to delivery unchanged. What’s that triangle look like??

    • John I agree. I’ve worked in situations where a particular employee was making a lot of mistakes in their work. They had training and support but they chose not to implement any of it or verbalize when they didn’t know something and ask for help. When I questioned them about it, having their work be right was not even a priority. They had excuses why they weren’t doing it right and did not realize the negative impact their errors were having on other employees’ work. You can provide all the training in the world and they still may not care about the errors in the work they produce.

    • I believe it’s really important to have the right resources on the project and that’s the key mistake that one should avoid. If you get people on-board who do not have the appropriate expertise required to perform the task at hand, then you will not only lose the time and money to get the job done but also will affect the reputation of you and your company in front of the client. Getting the right people determines the success and failure of your projects. While working on one of the projects in my earlier company, I had to bring on-board a new hire instead of an experienced person, as part of the company policy, to my team to perform code analysis for issues. However, the person was not technically sound, in which case whenever the technical issues surfaced, I had to get assistance from other colleagues who were part of the bigger team. This not only increased the overall resolution time for the issues but also adversely impacted the relationships with the customers and clients. The situation only changed after 5-6 months when the new-hire had gone through certain training’s and got some experience from handling some of the repetitive issues.

      • Rishabh,
        I agree with you that having the right people is the most important element of a project. Having team members with the right skills is more important than the number of team members you have or even how highly skilled they are. For example, at a publishing company, you could have a highly skilled data analytics expert on a team for a print magazine project that will only be tracked through the print circulation department. The data analyst could be brilliant, but his or her skills are not relevant to the project at hand. Without the right people on board, the project will not be successful.

    • I haven’t been in the decision making spot, but usually you can’t change the scope because you have commitment to the client or management and the only way to deliver is with a trade off of time and cost . I had a couple of projects where it took about a month, a month and a half more time to deliver the project with a higher cost respectively. The deadlines were very aggressive and had to take more time than expected because there were a lot of bugs, issues to be addressed.

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?

      The most important mistake to avoid from the “14 Common Mistakes” article is Staffing. This can be difficult for a project manager to accomplish if all staffing position are new to the project. In this example all participants have no history with the company thus no track record of knowledge/experience other than the individual’s previous work history. This would make it slightly more difficult in deciding which tasks are ultimately distributed to each individual or team. If the incorrect members are chosen (including the project manager), the best decision for the project could be over looked or disregarded, delays in task completions will occur, and team moral will diminish pushing the time line for completion further out.

    • I think #1 Mistake Projects lack the right resources with the right skills can be crucial for the project success to have some developers learn the things on the fly and even never had a similar experience or are short in the talent department for example. What happens is they drag down the whole team because some people are not good learners or don’t have good understanding of technology and you have to show them multiple times the same things over and over. They drag the project down because the senior resources who have to help them are allocating a lot of time to the guys who don’t have skills to contribute much. Sometime it’s not to blame the guys who can’t do the job, but the management who has given them the assignments without realizing the resource allocation format is not good for the project, but they are thinking how cool is new guys will learn the technologies. It is about the PMO experience and familiarity of the technology to know who, what and when, so we get to project mistake #2 the things are being tied up.

    • Margaret, that’s quite a creative application of the concept. Back in my home country, street food is quite popular and one can easily find similar stuff sold by different vendors right next to each other. One of the aspects which differentiated a particular vendor from others was the quality that was offered. People tend to go more to the vendor who although might took some more time but provided right flavors and quality food. Similar aspect I observed when I was in New York and went to have halal food from the popular and oldest kart located at the 53rd street. Because of the quality and flavors, one might easily have to stand in queue for 10-15 minutes to purchase the food but people were happy to wait and enjoy the relishing meal in the end.

    • Hi Brinn,
      Yes I agree my post is very close to yours if you don’t have the right resources you should be able to do the shuffling of the resources you have to bear less damage as possible, of course you may need an extra time to deliver, but still you can try most of it.

    • I agree that having a manager that ignores problems brought to his/her attention will lead to additional delays and time line expansions. Ignoring a problem in its initial state allows the problem to increase in size and accumulate additional rider issues that could’ve been resolved or never initiated if acknowledged when first presented. Managers play an integral role in a projects success. They must be able to maintain multiple projects, staff, and tasks to make sure minimal deviation occurs.

      • Brinn, I agree. Ignoring a problem lets it fester and get out of control. When I was working, we had a problem with one team member who was not pulling his weight. He came in late, blamed others for his mistakes, and almost always found a way to have others do his assignments (usually interns or recently hired employees). My manager did not get involved until his behavior impacted team morale, which made it difficult for her to reverse the damage. Another issue was that there was no documentation of his poor behavior so she was not able to penalize him under company policy. Her method was to create rules for the entire group that required everyone to submit what they worked on each day. While it was frustrating for us, all team members who were busy could easily explain what they had completed in a day. The problem employee did and he did not last long under the new policy.

    • Hi Rikki. This example is both sad and alarming when you work in an environment that it suppose to be patient centered, but revolves around health care insurance cost factors. It must be very difficult and frustrating when you as a stakeholder have (in essence) no controls over the major decisions, but witness the recourse there of. There should be some instances where cost, scope, and time hold no precedence over one another.

    • Give an example of a project on which you’ve worked (either professionally or otherwise) where you’ve had to make a tradeoff between time, scope, and cost. What factors affected your choice?
      Every client project I worked on as an editor involved a sacrifice of the deadline set by the client (time), the page length, design elements, amount of written pieces, etc., required (scope) or the budget set by the sales rep (cost). One specific project was a product safety guide for promotional products. The initial scope was for a 24 page guide with ads from various vendors that sold safe products. We finished writing and choosing art designs for the stories, but there were few advertisers as we neared the print date. The publisher decided to have one company sponsor the whole guide, which meant having that client approve all content and going up to 32 pages. I worked with the graphic designer to choose new art concepts that would allow us to keep our current stories, but have them fill more pages. We also worked heavily with our art department in India to turn around pages as quickly as possible. Ultimately, we were able to meet the print date (time) and come in with higher profit than expected (cost), but we had to sacrifice our initial design (scope).

    • Hi Bisser. I just read your response and agree with your stance. Resource allocation must be distributed in the correct fashion to allow a project to opportunity to succeed. Management must be able to choose the correct skilled staff across the board to handle the tasks (from minimal to detailed). Some staff will not have the same experience or knowledge as others, but the must have the willingness to learn and adapt to the environment or ask to be placed in a more suitable role to help the betterment on the project’s success. Managers must be able to access this ability and make the appropriate changes if staff is not willing to step forward with their concerns.

    • 2.Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?
      I believe that Mistake No 8:”They don’t take the time to define the scope of the project.” We have learned this week how the tripple constraint impacts the overall success of a project. The project scope involves identifying specific project goals, deliverables, tasks, costs and deadlines. Without a well defined and documented goal the project will lack the clarity and direction to complete the project on time and meet stakeholder’s expectations.

    • Hello Collen, I think your post is a good example on the role “flexibility” plays in the success of a project. I see that the guide had to accommodate s single sponsor which in turn led to a change in scope. Did the final print, in your opinion, turned out better than the original 24 page design?

    • To Biser:
      I struggle with this question because the project manager works with whom ever the HR department felt was a good fit to the company. When an HR hires the individuals with limited work/technology experience the organization suffers the consequences. Unfortunately, the blame falls on the shoulders of the Project manager who simply uses the resources HR hires to work on the projects. I see your point that these individuals consume resources rather than move the project forward.

    • To Rikki:
      I liked your example of the tripple constraint as it applies to the process of managed care at hospitals. I feel this is a good example

      where the lack of flexibility in the managed care process leads to a down stream clinical event requiring readmitance. Unfortunately, this is the norm for manage care rather than the exception and these types of rigid rules are a cause healthcare in the US is so expensive.

    • Hello Maria:
      I am wondering how long it took them to actually complete the project including FDA approval to sell a cheese product that in is non-dairy. One must not lose sight that in the business world time is money and while they have reduced the cost of making a non-dairy cheese product the development to market timeline must be taken into consideration.

    • Rikki, it is interesting to apply the triple constraint concept to people because the tradeoffs seem that much more detrimental. Your example makes be wonder what managed care providers are possibly thinking because it seems so obvious that this scenario ends up being more costly. I would like to think there is a method behind the madness and am really curious what that is — or if the system is truly that inefficient.

    • Colleen, I can certainly relate to a project changing scope near the end of a deadline. There were several times in my previous position when it seemed like every project I was working on was continually changing. Some would even change two or three times and then end up where they started. It seemed pointless to get attached to any decisions because I expected everything to change… and then change some more. It can be quite frustrating but certainly teaches you to work efficiently from getting so much practice with re-doing things!

      • Your comment reminded me of how I feel about our client project in the GMBA marketing class. It is a great project, but the scope keeps changing so we are having trouble maintaining momentum. Additionally, we are running into problems because our team is too big. The large team makes it more difficult to shift focus, especially when team members miss meetings. Sometimes a smaller team of highly skilled individuals is more effective than a 15 person team with varying skill levels.

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?
      I think the most important mistake to avoid is ignoring little problems. It is especially crucial when that error effects other parts of the project as well. Gradually, a lot of problems arise around the one thing ignored at the beginning. Problems can be ignored for two reasons – first there may be a lack of initiative among the team to report small things. Employees may not be motivated to report small issues in the fear that they may be assigned to work on it along with their regular tasks. The environment in the team may not encourage members to come forth with their findings that may not be related to their job task. Second, due to high pace of the project employees may simply forget about it. Both these situations can be turned around if the team lead or manager communicates and encourages the team to report little things. Updates can be given and followed upon during daily stand ups

    • Hi Rogelio, I couldn’t agree more. I remember during our EMC project we initially got a project scope along with the project description. We were paired with a PMBA team to work on different part of the project for the same client. Initially we had to spend some time defining the scope of our project and make sure it does not overlap much with the PMBA’s part. For our project itself, the scope was so wide that we had to limit it, given the time frame. Another factor that helped us deliver on time was that we had two extra resources from marketing to help us with data analysis. We learnt about balancing the three constraints this week and I think that for any project to succeed it is very crucial to hit the sweet spot – the circumcenter of this triangle.

    • Mistake #14: They don’t communicate well with project sponsors and stakeholders.
      Communication is #1 in my book on any project. Meetings and communication with all stakeholders is a priority. Expectations must be clear on each worker’s level of understanding. There are grammatical differences in language and there must be assurance that each individual understands their role and scope of the project. Time is of essence so someone has to keep an eye on the project workers and their work to make sure, they are clear on the directions of the project. Working from a spreadsheet can be done in many different ways based on each individual’s understanding. There can be many right ways, that is the reason, the work has to be monitored before time runs out and people get frustrated at the last minute. Once the work is on the right track in the first several weeks, then everyone can go about their own work at a faster rate, in a more accurate direction. meeting together as a group can enhance the flow , scope accuracy and communication of the projects.

    • Hi Margret, great example, I think a lot of people can relate to it. However high quality may not imply high cost all the time. Deviating from the food industry, when I think about balancing time, scope and cost, Southwest Airlines has done a really good job. Just last week we had a case study on Southwest Airlines for one of our classes. Southwest was able to achieve high quality or service (scope) at a low cost and with a higher turnaround time than most of the other airlines. On of the key take always was that most people associate high quality with cost. Here, I’m referring to quality as the quality of service, not expensive raw materials to help make the experience rich .

    • I would have probably done the same thing Pei. Once everything is all ready and in its last phase close to the deadline, I just want it over with. If everything was moved to another date, people may see us as not worth trusted. We would lose their confidence in us. Many times, there are issues at the last minute, but I always keep in mind, a Plan B.

    • Pei Yen
      In today’s time, we are finding out more and more about team work. Some people have never done it. They have always worked independently and it is very hard to support a team and work as one. I see divisions among work groups all the time. Everyone always says that the other guy is responsible for the issues. No one takes responsibility and just troubleshoots as a team. Teamwork has to be taught and learned in the present and future world. More time spent together in meetings and training can enhance team togetherness and responsibility.

    • Projects as well as day-to-day operations must be supported with the right resources in order to succeed. However, for projects specifically I am going with the #2 most common problem as #1 for me: “repeatable project management process”. As a fairly methodical person myself, i was appalled at my first project meeting to see that a “PM” had not even a pencil let alone a laptop, notepad, etc. I was told that she was considered a very good PM however. During the course of the meeting and others that had followed, it was really the “doers” who led the meeting, talked among themselves (in their own techno language), and drew up “next steps & time frames”. The PM only reiterated some key To-Do items and sent an Outlook meeting request based on the “doers” instructions. The project was successful due to the tactical actions taken and the fact that it had met a deadline within scope (delivered a service). I personally saw very little oversight or influence. Unfortunately, when a break-fix was needed months later, some of the players were gone and there existed very little documentation as to the build and critical decision points. The next round then included a new PM who was of the more traditional nature, took minutes, asked clarifying questions, tempered the”doers” and truly managed the project all while using entity-approved documentation tools.

    • Susan, I agree that communication is critical at every turn. Although most posts discuss “right resources”, that even can be hampered if the goal of the project is not clearly communicated. That is, in order to apply the right resources, the benefactor must be well aware of what the project entails. As I noted already, I think it is critical that consistent patterns communication patterns and formal documentation be employed at all turns. We have all seen organizations employ email templates, project proposal forms, etc that are meant to capture the formality of the organization’s communication methods. I support such attempts. Within our 100+ HR division, it has been mandated that all professional staff attend a two-day PM seminar with the goal being that we communicate more consistently within and between the various departments. To that end, i am charged with applying such techniques to our day-to-day”mini” project that arise within our HRIS department. These include quick fixes as well as longer-term projects. We start with the “initiation” sheet so as to clarify & communicate for ourselves the ultimate project scope. I am excited by this more methodical approach to communication.

    • As a golf professional planning tournaments can be considered a project. Our largest tournament of the year was the “Member-Guest” and their was a planning committee made up of the members as well as managers of the various departments. During meetings discussions almost always revolved around the issue of the triple constraint. The members wanted the tournament to be as extravagant as possible, but also as cheap as possible. My boss used to say “they want steak and lobster, but only want to pay for a cheeseburger.” In order to keep costs low we had to come to an agreement in a timely fashion to keep shipping cost low. Eventually we would come to a middle ground that provided a reasonable level of service (scope), for a decent price (cost), that fit within the schedule (time).

    • I agree Swetha. In my experience people tend to ignore small problems hoping that they will just go away. The issue is that someone needs to deal with these problems and they don’t simply go away. Small issues slow down the overall process and tend to grow larger as they’re ignored. Your reason that the environment of the team may not encourage people to come forward with issues is very true. Coming forward with an issue can sometimes be a touchy subject. Effective teams communicate openly to effectively deal with any issues that may arise.

    • Rishabh, going further with your example of street food. Even if the two vendors take a similar amount of time to produce their food at that time, I can guarantee that the high quality food vendor took more time and ultimately spent more money to seek out and prepare their ingredients.

    • I agree. Proper communication plays a very important role in the success of a project. While it may seem like a simple and most obvious thing to have enough communication within the team members, lack of proper communication can be seen more than often in projects.
      I had witnessed a similar issue in one of the projects that I had worked previously. The database testing team for our project started writing test cases and test scripts based on the initial communication with the client. After about two weeks of effort, when the team was ready to proceed with the testing process, they realized that the source from which data is supposed to be pulled was not yet ready. This caused a significant delay in delivering the project on time. This problem occurred due to lack of proper communication between the testing and development team.
      As seen in the CGI and Hubble project case, communication becomes even more important while working in distance projects because of various challenges such as time zone differences, language barriers, etc.

    • Rikki, this is a great example of the tradeoff between time, cost, and scope. I would argue that although we don’t like to think of them as projects, in this context people can be considered projects. If taken care of properly their inpatient stay should be temporary, there is a start and an end, you’re working within a budget. Obviously working with human beings is much less predictable than your typical project, the “deliverable” is not as clear, but can be measured by the doctor’s treatment goals.

    • Tom, your example represents how triple constraint issues are often solved: compromising on cost and scope to fit the timeline. I love the quote “they want steak and lobster, but only want to pay for a cheeseburger.” It is such a good explanation of how many clients treat consulting services, event planners, etc. I’m sure Lauren has worked on many weddings where they couple wanted Wagyu for the price of McDonald’s. On the publishing front, we had several clients who wanted the full scope of our services (video, print, web, e-learning) for the price of a print ad. There were times when the publisher would discount our services hoping that it would turn into more money in the future, but it often was not worth the impact it had on resources and cost to the company.

    • Give an example of a project on which you’ve worked  (either professionally or otherwise) where you’ve had to make a tradeoff between time, scope, and cost. What factors affected your choice?

      I can relate the experience of trading off between time, scope and cost in majority of development projects that i have worked in or observed other people working in. In my last company, there was hardly a resource that was 100% dedicated to development. The resource was partially in development and partially in support work, and when a resource is also in support work, he/she has to dedicate time from the development work to handle critical issue which can’t be delegated at the similar crucial time of development phase. At that moment, it was mostly that we have to trade off the time for the development project as we couldn’t miss the SLA for the support tickets and especially if they high or urgent tickets. I was stuck in the similar issue when i was working in a new development project and we newly adopted the agile methodology to execute the project. Since the deliveries were in sprints, we had a small turnaround time and the the next delivery was very close. At the time, there was critical support work that was brought for a project of which i was the designated SME. Since it was among the platinum (the highest ranked) applications, we in any condition couldn’t miss the SLA of the asked support work. At that moment, i had to stop working on the deliverables of the project, delegate the work to a subordinate and start working on the support work. This definitely affected the time and cost of the project. But since this wasn’t the final deliverable at that moment, we were able to recover the loss of work later. But this experience brought the managers ti rethink to reduce the scope or increase the time of the development project.

    • Rogelio, I lucked out because the client’s vision aligned closely with mine. I was happy with how the final guide turned out. It allowed me to get creative with art, which was one of my favorite parts of my job. In this example, the change in scope actually enhanced the final product. The biggest challenge was completing the pages and gaining approval from the client in time for print, but having a good rapport with the client was helpful in completing the guide on time.

    • Susan, i am totally with you that communication is very important in the execution of any work or project. There are many ways, and maybe considered right, which is so relative from one person to another. If the communication is not clear and proper, then the deliverable may not be as expected and then it will cost us more, in terms of time or money or even both. When i was working as an offshore member, it was critical to communicate well with the onshore members and the clients continuously, clearly and in sync. We couldn’t meet in person, so the entire project clarity was dependent on how well the communication was. Even while we were on call, or video conference, we used to share desktops, exchange IMs, at the same time. And that wasn’t it, there was one person who always used to send minutes of meetings to every attendants of the meeting so that at the end of the meeting, everyone was on the same page, followed by assigned action items.

    • Tom, your example is so to the point and simple. One can relate that with any service industry, where people want jobs to be performed and keep on demanding more and more but doesn’t want to pay for the amount of work they demanded. And also they want the tasks to be completed ASAP thinking that the service people are only loaded with their work. Every single time there will be meetings and discussions compromising on the time, cost and scope of any incoming work. Not even a single time i have experienced that the client or the service industry are happy or are in a common ground at the first go! And yes, loved your boss’s comment: “they want steak and lobster, but only want to pay for a cheeseburger.” 😉

    • Swetha, your point is so common and daily experienced in any project life cycle. I couldn’t agree more that small ignored problems when allowed to percolate through the ongoing project snowballs itself into a much bigger problem towards the end. There are quality checks that are initiated since the beginning of the project and there are standard checks that should be maintained at each level. But nothing will yield result if each employee doesn’t take an initiative to work towards it and report any issues on the go. Other way to encourage employees is to offer incentive. Like in the stand ups, recognizing people for recognizing defects and how it affected in reducing defects, having a wall of fame or something similar.

    • Hi Swetha-
      Southwest is an interesting case study in this regards. I wouldn’t say that the quality, meaning service, necessarily means the scope of their product is broad therefore requiring a cost tradeoff. I think quality service is still within a narrow scope of amenities offered in Southwest’s “product.” Given their minimal amenities I would still say they have a very small scope business, allowing for them to compete on a low cost platform.

    • Hi Brinn-

      I agree that staffing can be an insurmountable problem to avoid unless addressed at the very start of a project. It also seems difficult to predict which staffing decisions would be best, so avoiding this problem may be unavoidable at times (no one sets out to have a poorly staffed team).

    • Take a look at the “14 Common Mistakes” article from this week’s readings. Which mistake do you think is the most important to avoid? Why?

      I believe mistake no.2, “Projects lack experienced project managers” is a very crucial mistake that needs to be avoided. Hiring right people in the team is important for the success of the project. But, having a right person to manage the team is of greater importance. Without a proper direction, the probability of failure of the project is quite high.
      Good project managers learn from their past experiences, have a better understanding of the situation and would know exactly what has to be done to get a project on its tracks. Project managers are responsible for proper execution of the project and for allocating resources in economically efficient manner. A poorly handled project would make the costs go up significantly. As suggested in the article, project managers who are certified, and have significant prior experience and knowledge in the technology being deployed should be hired to manage the project. Extra efforts should be taken for the staffing process as having the right people in the team would reduce the problem greatly.

    • Hi Rogelio, I agree with your point. Oftentimes, the team members in a project won’t spend enough time in defining the scope. Starting the project with a vague idea can turn out to be dangerous. Even I had a similar experience as Swetha. In one of the projects for my marketing class, we spent a considerable amount of time narrowing the scope so as to have a defined limit and understand what needs to be done. I believe that this is the first logical step that needs to be taken care of before going ahead with executing the project.

    • I totally agree with you. Ignoring problems until they become bigger problems is the most common mistake.That’s a really nice point by John that small problems are often symptoms of larger ones. Addressing the problems in the initial stage would save lot of money and efforts. Usually, problems are ignored at the initial stage as they seem to be trivial or of no importance. And there may be no motivating factor to spend resources on a minute problem. But, there are chances that this leads to a larger problem and affect the overall deliverable.

  • Here are the instructions for the simulation assignment. You should have already purchased the simulation as part of the Harvard coursepack.

    We’ll discuss this in class this week. I’ll open the simu […]

  • Welcome to MIS 5801- Managing Information in the Enterprise, April 2016. We will be using this site for all course related activities and materials. Please bookmark this page. To  your left is general […]

  • Here are the case questions for the second half of the course.

    And don’t forget these grading guidelines to see how I evaluate your cases!

  • At the last Advisory Council meeting Munir Mandviwalla, MIS Department Chair, challenged the Council to become more committed to the success of the ITACS program.  Munir discussed his research into how committed […]

  • Load More
Skip to toolbar