The Challenges of Company Wish Before I attended II Business School I worked for The Boeing Company in the Space & Intelligent Systems sector. To quickly summarize my responsibilities, I helped design, build, test, and launch satellites for both commercial and government customers. Working in a highly technical field for a big corporation a significant portion of my time was spent on one of two things: 1) Documenting my knowledge or experiences on a specific subject. 2) Searching for information or knowledge on a specific subject using a variety of methods and tools (servers, internet, intranet).
I became an engineer to build, design, & create and as such, I found both of these tasks to be as boring as they sound. However, after spending years in the industry, I came to understand the importance of both of these tasks in order for a large company like Boeing to continually build successful high-tech products. In order to accomplish these tasks, most large companies, including Boeing, are moving towards web or enterprise 2. 0 tools such as: internal knowledge-management databases, wish, or intranets. These tools are all working to effectively and efficiently create a en-stop shop for employees to share or obtain information from past experiences in hopes of not “reinventing the wheel”, as the Jargon goes. The challenge I want to approach is how companies can build and manage one of these digital projects so that it succeeds in accomplishing what it was set out to do, specifically internal wish. As an intern in 2007, I was tasked with the Job of conceptualizing and building Boeing’s internal wick along with 3 other interns and a project manager.
A wick is a web application that allows people to add, modify, or delete content in collaboration with others. As interns, it was almost impossible for us to fully understand what users (employees) really wanted from the wick. It was also a challenge for us to conceptualize a manner in which to design the wick such that it could encompass the millions of technical documents that Boeing had somewhere lying around on an obsolete server, and how to accomplish this in an effective manner.
After a year of searching and obtaining useful or relevant information for the wick, and creating multiple beta versions, we presented our final version to management and received the go-ahead to release the wick “into the wild”. By 2012, the wick had exploded with enormous amounts of content, but the content was difficult to find and was not always trustworthy. Personally, I rarely used the wick because I was never able to find exactly what I was looking for. I would have to spend more time searching the wick, than I would have spent tracking down one the technical experts who could answer my problem.
While I would not classify the wick as a complete failure overall, I would not constitute it as a success either. There are three key reasons listed below on why the wick was not as successful as it could have been: Lack of understanding of stakeholders needs Lack of documentation via the experts Lack of a dedicated team for maintenance or quality and change control The initial design started with 3 interns and a manager. With very little experience between the three of us, it made it quite difficult to understand the real purpose for the wick.
Although our design was sound in the initial versions, once the wick caught on within the company, the structure and design was not sufficient enough to effectively handle all the data being put onto the wick. Hence, at any one point there may have been 10-20 “children pages”, or links, for the user to acquire the information needed. As Dolomite says “involve stakeholders in the selection process and ensure that the solution meets the business requirements”. 3 In Boeing’s case, we did neither.
If you have ever worked for a technology company, you may know that a technical expert’s time is precious. More often than not, they are too busy designing something or solving a problem, leaving them very little time leftover to document their findings. As a result, most submissions on the wick I found were from people who were not the technical expert in the subject and it was evident in their postings. Instead, the stings were coming from engineers who, to be blunt, were seat-fillers. There was no control system to ensure the documentation was correct, of good quality, and reliable.
When submissions are not trustworthy, the entire wick concept can lose its credibility, as it did in my experience. Additionally, as the wick evolved and grew in the 5 years I was present at Boeing, never was there a restructuring or redesign of the wick. This, in combination with the initial design, made it difficult to find information easily and quickly. Taking all of this into account, what solution is there for large technology firms trying o create and implement a wick? First, as with any digital project, there has to be a clear understanding of what the need is.
Without this, the design will ultimately fail and all subsequent steps thereafter. Easier said than done, but a way to minimize this risk is to ensure digital projects have a variety of team members working on the project from the start. This should include an experienced manager and a technical expert. Secondly, there should always exist a mentor/proto©g© relationship between the experts. As a result, there is no single expert in one particular field, thus allowing mime for trustworthy and credible documentation.
Lastly, digital projects are not a one-time thing. They are continuously evolving and there must be some adaptability in order to account for these changes. Wish are powerful tools, if implemented correctly. They can allow novice employees of firms to learn on the Job from documentation of past experiences instead of taking up an expert’s time tort meetings and training. Thus, through the implementation to a well-designed and maintained wick, a company can save time and costs for both the novice and the expert, and in the end everyone wins.