Just another Temple Fox MIS site

Weekly Question: Week 13

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 responsesRemember, you need to average four posts a week for a B. For these weekly questions, I’m mainly interested in your experiences and opinions, not so much particular “facts” from the class!

Answer one of the questions below:

  1. Describe a project (a technology project if possible) with which you have been involved that caused a power shift within an organization.
  2. 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.

95 Responses to Weekly Question: Week 13

  • 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.

    • 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. 🙂

    • 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?

    • 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.

  • 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.

    • 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.

  • 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.

      • 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!

    • 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.

  • 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.

    • 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?

    • 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.

    • 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 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.

    • 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?

      • 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.

    • 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.

  • 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.

      • 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?

    • 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.

    • 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.

  • 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.

    • 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.

    • 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 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.

    • 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.

  • 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

    • 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.

    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.

    • 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?

      • 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.

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

          • 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.

    • 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.

    • 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.

  • 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.

    • 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?


      • 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.

  • 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.

    • 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.

  • 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.

    • 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.

    • 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.

    • 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.

    • 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.

  • 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.

  • 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.

    • 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.

  • 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.

  • 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.

    • 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.

  • 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..

  • 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 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

  • 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.

Leave a Reply