What if you do not believe in the project benefits?












13















I've recently been assigned to a project as the PM and I'm fairly sure that a senior executive in the company has heard some fancy marketing spill at a conference and now wants this product at the company.



As far as I can see, it is an expensive and specialised application to coordinate much more complicated infrastructure than what we have and there is no use case for this product at this company.



I've tried explaining this but there is a lack of technical knowledge and the managers have expectations of all these proposed benefits, all of which are hypothetical and frankly unrealistic.



What is my responsibility here? Do I just accept that even through I disagree with the project benefits, I've been given this task to purchase and integrate this application so that should be my goal?



How do I protect myself when the application inevitably does not do everything that management expect it to do? Morally, should I step down as the PM for this project?










share|improve this question



























    13















    I've recently been assigned to a project as the PM and I'm fairly sure that a senior executive in the company has heard some fancy marketing spill at a conference and now wants this product at the company.



    As far as I can see, it is an expensive and specialised application to coordinate much more complicated infrastructure than what we have and there is no use case for this product at this company.



    I've tried explaining this but there is a lack of technical knowledge and the managers have expectations of all these proposed benefits, all of which are hypothetical and frankly unrealistic.



    What is my responsibility here? Do I just accept that even through I disagree with the project benefits, I've been given this task to purchase and integrate this application so that should be my goal?



    How do I protect myself when the application inevitably does not do everything that management expect it to do? Morally, should I step down as the PM for this project?










    share|improve this question

























      13












      13








      13


      1






      I've recently been assigned to a project as the PM and I'm fairly sure that a senior executive in the company has heard some fancy marketing spill at a conference and now wants this product at the company.



      As far as I can see, it is an expensive and specialised application to coordinate much more complicated infrastructure than what we have and there is no use case for this product at this company.



      I've tried explaining this but there is a lack of technical knowledge and the managers have expectations of all these proposed benefits, all of which are hypothetical and frankly unrealistic.



      What is my responsibility here? Do I just accept that even through I disagree with the project benefits, I've been given this task to purchase and integrate this application so that should be my goal?



      How do I protect myself when the application inevitably does not do everything that management expect it to do? Morally, should I step down as the PM for this project?










      share|improve this question














      I've recently been assigned to a project as the PM and I'm fairly sure that a senior executive in the company has heard some fancy marketing spill at a conference and now wants this product at the company.



      As far as I can see, it is an expensive and specialised application to coordinate much more complicated infrastructure than what we have and there is no use case for this product at this company.



      I've tried explaining this but there is a lack of technical knowledge and the managers have expectations of all these proposed benefits, all of which are hypothetical and frankly unrealistic.



      What is my responsibility here? Do I just accept that even through I disagree with the project benefits, I've been given this task to purchase and integrate this application so that should be my goal?



      How do I protect myself when the application inevitably does not do everything that management expect it to do? Morally, should I step down as the PM for this project?







      ethics






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Feb 21 at 11:05









      ShoesShoes

      6613




      6613






















          4 Answers
          4






          active

          oldest

          votes


















          10














          There's a conflict between the Product management and the Project management role.



          As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.



          As Project Manager, you're responsible to ensure the project objectives are achieved.



          Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.



          By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.



          If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.



          Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.





          * IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.






          share|improve this answer































            10














            Agree with @Tiago Cardoso, but I'll provide a different analytical framework.



            The PM is responsible to the stakeholders for closing the project.



            If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).



            If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.



            Were I in your shoes I would:




            1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.


            2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.


            3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.


            4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.


            5. Work with the other stakeholders to build a coalition to manage expectations for the project ( nemawashi with a grateful tip of the hat to @kubanczyk)



            And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.






            share|improve this answer

































              3














              As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.



              However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".



              Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.



              Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).



              To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.



              What I'm driving at is that:




              • I stood up for my concerns

              • I let him have the final decision

              • When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course

              • He changed course and all was well


              Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.



              What you DON'T want to do is:




              • not say anything out of timidity

              • overstate your concerns

              • create a self-fulfilling prophecy (by causing the failure)

              • make it personal


              All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.



              I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.



              Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.



              The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.






              share|improve this answer































                2














                For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.



                I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.



                If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.






                share|improve this answer























                  Your Answer








                  StackExchange.ready(function() {
                  var channelOptions = {
                  tags: "".split(" "),
                  id: "208"
                  };
                  initTagRenderer("".split(" "), "".split(" "), channelOptions);

                  StackExchange.using("externalEditor", function() {
                  // Have to fire editor after snippets, if snippets enabled
                  if (StackExchange.settings.snippets.snippetsEnabled) {
                  StackExchange.using("snippets", function() {
                  createEditor();
                  });
                  }
                  else {
                  createEditor();
                  }
                  });

                  function createEditor() {
                  StackExchange.prepareEditor({
                  heartbeatType: 'answer',
                  autoActivateHeartbeat: false,
                  convertImagesToLinks: false,
                  noModals: true,
                  showLowRepImageUploadWarning: true,
                  reputationToPostImages: null,
                  bindNavPrevention: true,
                  postfix: "",
                  imageUploader: {
                  brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                  contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                  allowUrls: true
                  },
                  noCode: true, onDemand: true,
                  discardSelector: ".discard-answer"
                  ,immediatelyShowMarkdownHelp:true
                  });


                  }
                  });














                  draft saved

                  draft discarded


















                  StackExchange.ready(
                  function () {
                  StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25853%2fwhat-if-you-do-not-believe-in-the-project-benefits%23new-answer', 'question_page');
                  }
                  );

                  Post as a guest















                  Required, but never shown

























                  4 Answers
                  4






                  active

                  oldest

                  votes








                  4 Answers
                  4






                  active

                  oldest

                  votes









                  active

                  oldest

                  votes






                  active

                  oldest

                  votes









                  10














                  There's a conflict between the Product management and the Project management role.



                  As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.



                  As Project Manager, you're responsible to ensure the project objectives are achieved.



                  Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.



                  By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.



                  If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.



                  Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.





                  * IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.






                  share|improve this answer




























                    10














                    There's a conflict between the Product management and the Project management role.



                    As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.



                    As Project Manager, you're responsible to ensure the project objectives are achieved.



                    Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.



                    By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.



                    If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.



                    Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.





                    * IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.






                    share|improve this answer


























                      10












                      10








                      10







                      There's a conflict between the Product management and the Project management role.



                      As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.



                      As Project Manager, you're responsible to ensure the project objectives are achieved.



                      Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.



                      By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.



                      If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.



                      Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.





                      * IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.






                      share|improve this answer













                      There's a conflict between the Product management and the Project management role.



                      As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.



                      As Project Manager, you're responsible to ensure the project objectives are achieved.



                      Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.



                      By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.



                      If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.



                      Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.





                      * IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Feb 21 at 11:44









                      Tiago CardosoTiago Cardoso

                      5,35231852




                      5,35231852























                          10














                          Agree with @Tiago Cardoso, but I'll provide a different analytical framework.



                          The PM is responsible to the stakeholders for closing the project.



                          If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).



                          If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.



                          Were I in your shoes I would:




                          1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.


                          2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.


                          3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.


                          4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.


                          5. Work with the other stakeholders to build a coalition to manage expectations for the project ( nemawashi with a grateful tip of the hat to @kubanczyk)



                          And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.






                          share|improve this answer






























                            10














                            Agree with @Tiago Cardoso, but I'll provide a different analytical framework.



                            The PM is responsible to the stakeholders for closing the project.



                            If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).



                            If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.



                            Were I in your shoes I would:




                            1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.


                            2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.


                            3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.


                            4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.


                            5. Work with the other stakeholders to build a coalition to manage expectations for the project ( nemawashi with a grateful tip of the hat to @kubanczyk)



                            And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.






                            share|improve this answer




























                              10












                              10








                              10







                              Agree with @Tiago Cardoso, but I'll provide a different analytical framework.



                              The PM is responsible to the stakeholders for closing the project.



                              If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).



                              If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.



                              Were I in your shoes I would:




                              1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.


                              2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.


                              3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.


                              4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.


                              5. Work with the other stakeholders to build a coalition to manage expectations for the project ( nemawashi with a grateful tip of the hat to @kubanczyk)



                              And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.






                              share|improve this answer















                              Agree with @Tiago Cardoso, but I'll provide a different analytical framework.



                              The PM is responsible to the stakeholders for closing the project.



                              If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).



                              If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.



                              Were I in your shoes I would:




                              1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.


                              2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.


                              3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.


                              4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.


                              5. Work with the other stakeholders to build a coalition to manage expectations for the project ( nemawashi with a grateful tip of the hat to @kubanczyk)



                              And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.







                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Feb 22 at 11:15

























                              answered Feb 21 at 13:34









                              Mark C. WallaceMark C. Wallace

                              5,91222136




                              5,91222136























                                  3














                                  As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.



                                  However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".



                                  Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.



                                  Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).



                                  To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.



                                  What I'm driving at is that:




                                  • I stood up for my concerns

                                  • I let him have the final decision

                                  • When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course

                                  • He changed course and all was well


                                  Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.



                                  What you DON'T want to do is:




                                  • not say anything out of timidity

                                  • overstate your concerns

                                  • create a self-fulfilling prophecy (by causing the failure)

                                  • make it personal


                                  All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.



                                  I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.



                                  Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.



                                  The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.






                                  share|improve this answer




























                                    3














                                    As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.



                                    However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".



                                    Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.



                                    Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).



                                    To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.



                                    What I'm driving at is that:




                                    • I stood up for my concerns

                                    • I let him have the final decision

                                    • When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course

                                    • He changed course and all was well


                                    Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.



                                    What you DON'T want to do is:




                                    • not say anything out of timidity

                                    • overstate your concerns

                                    • create a self-fulfilling prophecy (by causing the failure)

                                    • make it personal


                                    All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.



                                    I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.



                                    Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.



                                    The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.






                                    share|improve this answer


























                                      3












                                      3








                                      3







                                      As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.



                                      However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".



                                      Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.



                                      Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).



                                      To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.



                                      What I'm driving at is that:




                                      • I stood up for my concerns

                                      • I let him have the final decision

                                      • When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course

                                      • He changed course and all was well


                                      Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.



                                      What you DON'T want to do is:




                                      • not say anything out of timidity

                                      • overstate your concerns

                                      • create a self-fulfilling prophecy (by causing the failure)

                                      • make it personal


                                      All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.



                                      I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.



                                      Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.



                                      The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.






                                      share|improve this answer













                                      As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.



                                      However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".



                                      Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.



                                      Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).



                                      To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.



                                      What I'm driving at is that:




                                      • I stood up for my concerns

                                      • I let him have the final decision

                                      • When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course

                                      • He changed course and all was well


                                      Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.



                                      What you DON'T want to do is:




                                      • not say anything out of timidity

                                      • overstate your concerns

                                      • create a self-fulfilling prophecy (by causing the failure)

                                      • make it personal


                                      All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.



                                      I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.



                                      Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.



                                      The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Feb 21 at 15:13









                                      RuminatorRuminator

                                      1312




                                      1312























                                          2














                                          For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.



                                          I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.



                                          If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.






                                          share|improve this answer




























                                            2














                                            For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.



                                            I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.



                                            If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.






                                            share|improve this answer


























                                              2












                                              2








                                              2







                                              For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.



                                              I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.



                                              If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.






                                              share|improve this answer













                                              For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.



                                              I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.



                                              If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.







                                              share|improve this answer












                                              share|improve this answer



                                              share|improve this answer










                                              answered Feb 21 at 13:59









                                              David EspinaDavid Espina

                                              30.6k32281




                                              30.6k32281






























                                                  draft saved

                                                  draft discarded




















































                                                  Thanks for contributing an answer to Project Management Stack Exchange!


                                                  • Please be sure to answer the question. Provide details and share your research!

                                                  But avoid



                                                  • Asking for help, clarification, or responding to other answers.

                                                  • Making statements based on opinion; back them up with references or personal experience.


                                                  To learn more, see our tips on writing great answers.




                                                  draft saved


                                                  draft discarded














                                                  StackExchange.ready(
                                                  function () {
                                                  StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25853%2fwhat-if-you-do-not-believe-in-the-project-benefits%23new-answer', 'question_page');
                                                  }
                                                  );

                                                  Post as a guest















                                                  Required, but never shown





















































                                                  Required, but never shown














                                                  Required, but never shown












                                                  Required, but never shown







                                                  Required, but never shown

































                                                  Required, but never shown














                                                  Required, but never shown












                                                  Required, but never shown







                                                  Required, but never shown







                                                  Popular posts from this blog

                                                  How to change which sound is reproduced for terminal bell?

                                                  Can I use Tabulator js library in my java Spring + Thymeleaf project?

                                                  Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents