Organization Strategy and Project Selection – Trampled by the White Elephant

About one year ago I was given the opportunity to work on an inquiry that involved a technology for which I had limited exposure. As an engineer I was incredibly excited, but also fearful of what I didn’t know and the time it would take to learn it. I am one of a handful of engineers in my department and there are only two other engineers at the company familiar with the technology – one is semi-retired and the other one works in another department. The inquiry was passed along to me from two heads of engineering that were themselves mostly unfamiliar with the details of the specific technology, but consulted with the “experts” and decided that we should proceed with lab scale testing. However, we didn’t have the equipment to do the testing onsite. My first task was to specify the needed lab equipment and come up with a budget. The charge to the customer for conducting the testing was just enough to cover the cost of the equipment so it seemed like a good opportunity overall – gain hands on experience, get new equipment for the lab and potentially go on to sell commercial equipment.

Once the equipment arrived I ran a series of tests which took, in total, about six full weeks over the course of six months. The tests got progressively better as I learned from mistakes and refined the procedure. I directed questions to the “experts” as they arose, but often found that the questions I needed to ask weren’t apparent until it was too late. On top of that, the responses I received weren’t exactly “expert” level.

After the testing was complete, the customer finally sent the RFQ so that we could design and quote commercial equipment. Upon reviewing I found that request was over my head. I reviewed the RFQ with the “experts” – one said it was “mind-boggling” and outside of our expertise, the other said we would need to run even more tests before we could quote. Just last week I had to go back to the customer and let them know that we are unable to provide a quotation and don’t have enough resources to conduct additional testing.

Since we just discussed project selection in class, I thought this was a great example of how chasing the wrong projects can get you trampled by the “White Elephant”. If anyone had asked any of the following questions at any time during the project we could have prevented wasted effort and embarrassment.

  • What specific strategy does this project align with?
  • What are the project objectives?
  • Who is the project sponsor?
  • Will resources be available for this project?

While I feel like the problem originated from the head engineers/management, I know that I am not blame free. I’m curious if I had MGT 598 one year ago if I would have approached the project more wisely or if I just needed the failure to open my eyes.

I think there are many other questions we could have asked along the way to save face. Do you have any advice for me or my department?


6 thoughts on “Organization Strategy and Project Selection – Trampled by the White Elephant

  1. This was a fun blog post to read since it was a “real time” issue. After reading, I felt that there were a few pieces of advice or strategy that I felt would be beneficial to the project:

    1. Alignment of Strategy from top level management to project level management to engineering: By having this alignment, perhaps the company, if it had targeted this piece of technology on its strategic road map, would have identified the gaps in testing, expertise, equipment, etc. up front. Even if the project, although difficult and new, was still selected, the scope of the project would have been more understood, and the questions and interaction with the customer would perhaps have been more apparent up front. In this case, the “gap” between development and commercialization could have been more understood.

    2. Bid/No-Bid strategy: This does flow into (1), however, it is in addition to strategy of the company. The bid/no-bid selection process for projects may have identified that equipment was not available, expertise was not yet developed and resources were not entirely available. This may have created a scenario in which the project was “no bid” in order for the company to improve the “gaps” it had prior to customer exposure. This circumstance could have potentially avoided the issue of “no bidding” the RFQ after doing 6 months of testing (and gosh I would be rich if I had a penny for every time our company went through this same process as your company did!)

  2. Thank you for sharing this valuable experience.

    It is easy for companies to justify taking on new projects if they believe a particular project will lead to profits in the near future, or if it will provide their employees with valuable skills for future opportunities. It seems like it would have been difficult for any individual in this position to succeed, as the chances for successful project completion are strongly dependent on managerial guidance. The support and feedback received from upper management lacked the directions needed to make this opportunity beneficial. My only advice would be to possibly implement a stage – gate procedure, as these tend to be very successful with new technologies.

  3. Thank you for sharing your experience with the group. I think that almost everyone has experienced a project failure in one form or another. It seems that your organization is very lean with a limited amount of resources, so aside from your direct responsibilities as an engineer, majority of project management responsibilities were assigned to you as well, which sometimes could be hard to handle. I think that it would be beneficial to your company to refine project selection process, to establish management standards, processes, procedures, to have teams in place and to provide consistent project management support when taking a project on board.

  4. I enjoyed reading your post and the ‘real world’ component made me think about how our company, specifically our department, used to work with our IT department for new project requests. We would simply submit a very general outline form of the requested project/change we wanted implemented, and IT would begin to come up with hours needed for on and off shore work, hardware estimates, Project managers hours, dates and time lines for planning, building, coding, testing, and production releases. The entire process was very inefficient and the majority of the time, at least from my personal experience, the estimated cost from IT far outweighed the benefits of the initial request. We now have a more structure request process with a business objectives and requirements, problem and opportunity statements, benefit estimates, and impact statements for the project. However, even before filling out the very defined web based templates, what I found works even better is to simply set-up an 30 minute meeting with my IT counterpart to discuss the project and potential solutions. A lot of the times just from discussing the project requirements in very quick detail our IT expert had a faster, simpler, and cheaper solution than what I would have been purposing in the request forms. Either that or their ‘ball park’ estimate was so far outside the budgeted spend for the project that additional methods were discussed prior to submitting the documents online. A 30 minute meeting could eliminate a lot of time and effort spend by both departments filling out forms, revising budget timelines and estimates, and the back-and-forth of changes to the proposal just to potentially end up at the same outcome. I am not sure if this would have been an option in the future for your company, to see a pre-RFQ from the customer get a better understanding of the scope of their request prior to going through the entire process (maybe that was kind of what the initial inquiry was). From my department’s view, structured forms for requests are very helpful and of course needed from a corporate standpoint, but I feel the informal conversations with IT offer invaluable insights to the options and outcome without having to go through the full documented process.

  5. While I’m sure this wasn’t a pleasant experience, I think it speaks volumes to project management skills and having the tools necessary at any level to step back from a project and ask, “why are we doing this?”

    I’ve been in a similar situation, where a pet project got much further into the pipeline than it ought to. Problems began when our department ran into staffing issues. We simply didn’t have enough people on payroll to even staff an event, let alone staff positions with qualified individuals. I too wonder, if I had the experience from MGT598 before we had accepted the proposal and worked on scheduling the event – would I have been the one to raise the red flag?

    I think your situation also speaks to the communication required in a project management setting. In addition to the questions that could have raised concerns early on, whom in a formal project management setting is the key communicator when a project fails? or becomes out of scope/resources? In addition to project selection tools, it seems that it might also be beneficial to have an exit strategy or potential go/no-go point where the project can be re-evaluated. I’m hoping to propose a similar threshold in my own department, so if pet projects do manage to make it into our pipeline, there can be an emotion-free “reject button” that will cause it to be re-evaluated on the basis of scope, resources required, and current staffing workload.

  6. It was interesting and helpful to read your experience, it made me think that sometimes we focus more on task completion than strategical.
    And it becomes altogether more important to learn such real life examples and analyze what should have been done while studying Project Management from different people’s point of view than spending lot of time and money on wrong projects/tasks.
    It made me think about, the questions you have put, can those should be included in PM tools and revisited and re answered frequently like.

    Before taking project if each project step should be tied with its resources and and tying it with NPV and time value and connecting it with go-no go strategy,project alignments and project objective; can “While Elephant” situation be avoided.

    And I would also like to know, Does this experience made your company or customer to look for new approach?

Leave a Reply

Your email address will not be published. Required fields are marked *