As a Senior IT Network Project Manager with Avanade for 3 years and Network Implementation Project Manager for AT&T Mobility for 6 years prior, I highly recommend John Therrell as a candidate for employment. John was an intern with Avanade starting in January, 2008 and I had the pleasure of working with John on two specific projects:

· Network Security Monitoring – The Network Security Monitoring system is a security toolset that will allow ITS department to identify and monitor network behavior, utilization, and configuration for security, capacity planning, and maintenance.
· BitLocker Deployment – Microsoft® BitLocker™ Drive Encryption protects data when a computer is in unauthorized hands or is running an exploiting operating system. BitLocker does this by preventing an unauthorized user who boots another operating system or runs a software hacking tool from breaking file and system protections, or even viewing the files that make up the operating system itself.

John’s role on both projects was Quality Assurance Specialist. He was held accountable for all aspect of Quality Assurance and Testing including planning, test case creation/execution and defect tracking/resolution for the projects. John successfully completed his deliverables, adjusting planning and execution according to customer needs while maintaining the high-level quality we demanded.

Some of the skills and knowledge I witnessed John used to complete these deliverables:

· Understood QA activities in relation Avanade project implementation methodology
· Developed QA Plan and all test cases
· Provided good estimates for task duration
· Identified QA process issues and either provided solution or escalated
· Managed defects and resolution path
· Actively participated on project team, clearly providing QA skills and knowledge

From my Project Manager perspective, John was very easy to work and I appreciated his proactive attitude with ways QA could improve delivery. His interpersonal skills make him an excellent team member. John demonstrated he could work independently, utilizing his organizational skills. Our customer changed focus and priority during the Network Security Monitoring project which resulted in significant changes to QA Plan. John was never deterred, instead reaching out to the customer to completely understand his needs resulting in high quality test cases. John also worked closely with other teams on a number of occasions and was able to juggle his priorities accordingly.

I would therefore highly recommend John Therrell. If his performance on these two projects is a good indication of how he would perform as a employee, he would be an extremely positive asset to your organization and company.

If I can be of any further assistance, or provide you with any further information, please do not hesitate to contact me.

Sincerely,

Greg Paskett | Sr Specialist, Program Mgmt
ITS Hosting, Network & Information Security
Avanade Inc | Seattle Service Center
818 Stewart St., Suite 400, Seattle, WA 98101

Letter of Recommendation for John Therrell

I hired John Therrell as an SE intern on Avanade’s Infrastructure QA team in January of
2008. During his internship I was his direct supervisor up until my departure from
Avanade in June of2008.

In a largely Microsoft environment, John provided support for our physical and virtual
server environments ranging from hardware installations to software deployment and
troubleshooting. He was a valued team member who brought an attention for details to
his work. John worked well with our cross functional teams and had many opportunities
to assist these teams in an Infrastructure QA capacity. The feedback I received from
other team members was positive and I was happy to have John represent our team with
technical project efforts.

Some projects and/or tasks of note that John played a role in include: Vista bitlocker
deployment testing, writing and executing test cases for Infrastructure QA projects, and
assisting with the migration of Microsoft Virtual Server 2005 virtual machines to a
clustered Hyper-V environment.

John’s professional manner and willingness to collaborate added to his value as a team
member. It was a pleasure working with John and I am happy to provide this letter of
recommendation and to see his career continuing in the Information Technology field.

Regards,

Brent Sommerseth
Avanade QA Infrastructure Team Lead/Supervisor 2006-2008

Details coming soon!

Morbi vel pretium sapien. Morbi dignissim, leo sit amet rhoncus laoreet, tellus metus dignissim purus, vitae egestas eros mi non sem. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Fusce non lacus eu enim mollis blandit. Nullam ultricies tortor quam, ut cursus mauris. Etiam nec nisi nec leo fringilla iaculis. Nullam eu sapien at quam sagittis dapibus quis non nisl. Sed et lacus arcu, quis vulputate sapien. Phasellus congue interdum eros, eget iaculis neque luctus non. Nunc tempor, felis id tincidunt consequat, ipsum mi faucibus nisl, quis molestie est nibh vitae nisi. Sed congue, massa ac posuere luctus, enim eros luctus mauris, et imperdiet turpis nulla et sem. Curabitur hendrerit massa a lacus scelerisque eget placerat metus lacinia. Nulla facilisi. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Fusce tincidunt libero at odio malesuada consectetur. Nunc non pharetra nulla. Integer hendrerit augue fringilla nibh accumsan consectetur. Nullam sodales orci vel ante sodales tincidunt. Duis facilisis metus ut nunc interdum accumsan. Aliquam eu libero quam.

Nunc id sagittis ligula. Integer nec lorem arcu. Quisque vitae eros odio, non volutpat augue. In laoreet vestibulum orci nec rhoncus. Maecenas vulputate dapibus iaculis. Donec lacus erat, ornare et molestie nec, accumsan a lorem. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Mauris ut accumsan purus. Mauris velit risus, sollicitudin at elementum non, mattis vel felis. Morbi volutpat porttitor ante quis hendrerit. Nulla magna ligula, blandit sed malesuada molestie, sodales sed leo.

Fusce aliquet tellus ut sem sagittis eleifend. Etiam porttitor viverra mollis. Pellentesque pellentesque imperdiet magna vitae vulputate. Donec in interdum tellus. Morbi ultricies, orci scelerisque porttitor iaculis, augue quam cursus urna, ac sagittis justo elit eget sem. Sed in massa in diam tempus laoreet. Sed risus erat, placerat a convallis vitae, molestie et ligula. Aliquam erat volutpat. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Phasellus venenatis mollis leo, ullamcorper blandit orci aliquam sit amet. Proin turpis quam, malesuada id ullamcorper eget, imperdiet nec elit. Suspendisse nibh ipsum, auctor eget tempus molestie, gravida a sapien. Aenean eu lacus est, ac tempus velit. Morbi ut tellus et lacus tristique suscipit. Vivamus augue sem, pulvinar sed dapibus placerat, auctor et est. Maecenas consectetur est vel nunc porttitor tincidunt venenatis nunc sagittis. Sed et nulla libero, ac dignissim urna.

An Examination of a Company That Followed the Model

Documentum Inc – Document Management System

Documentum Inc. was in a fantastic position when their enterprise-level Document Management System software was released. Its venture capitalist investors were advocating towards a marketing strategy that would target the entire mainstream market (Lal and Lanagan 7). At the time, all of Documentum’s competitors were marketing to the entire mainstream market (Lal and Lanagan 6). Documentum’s new CEO, Jeff Miller, had a difficult decision to make when he ultimately chose to follow Moore’s Chasm Model and focus on a vertical market segment opposed to a horizontal market strategy.

Documentum followed the Chasm Model’s target market selection process exactly as prescribed by Moore. Documentum not only adopted the Chasm Model as their Marketing Strategy, but also paid to have Geoffrey Moore’s Chasm Group provide consultation to the company and assist in identifying potential market segmentations for the company to target. After the analysis, the following five market segments were suggested: Insurance Policy Documentation, Aircraft Maintenance Documentation, Pharmaceutical NDA, Chemical Regulation Management, and Telecom Manufacturing (Lal and Lanagan 8).

From their market segment analysis, Documentum chose to target the Pharmaceutical NDA as their niche market. The business process they chose to target was the labor intensive task of preparing a new drug application for the Food and Drug Administration (“History of Documentum, Inc”). A new drug application consisted of hundreds of thousands of pages, which cost pharmaceuticals a considerable amount of money in labor required to compile and organize the application. Documentum saw an opportunity where their software could help shed off time and expenses associated with this business process.

With a clear vision of the beachhead to attack, Documentum made changes to their document management system software to add customization to support the FDA application process. After these changes were made, the company began to shop their product around to big pharmaceutical companies like Merck and GlaxoSmithKline. Merck and GlaxoSmithKline became adopters of the product and other pharmaceutical manufacturers soon followed.

From 1993 to 1994, Documentum increased revenues by from $2M to $10M, with revenues from pharmaceuticals accounting for 70% of their total revenue. From this strong position in their beachhead market, Documentum was able to continue its domination over other vertical market segments successfully (“History of Documentum, Inc”). The ultimate mark of success happened when EMC ended up acquiring Documentum for $1.7 billion in December 2003. Documentum followed the Chasm Model and was rewarded heavily for their decision to do so.

An Examination of Companies That Fell From the Model

Linden Labs – Second Life

In 1999, Linden Labs, creator of Second Life, was founded by Phillip Rosedale after his move from Real Networks to focus on the development on his vision for Second Life. He imagined a virtual world that would immerse its customers in massively multiplayer interactive environment. In 2003, Second Life launched and immediately was faced with skepticism that demand would be low for its virtual world without a story or game supporting the user experience (Eisenmann and Wagonfeld 1). When the company approached the chasm, it attempted to follow the Chasm Model, however, did not shown that it followed Moore’s marketing strategy as it is prescribed in his book.

Over the first five years of Second Life’s operation, Linden Labs has seen a total of 16.8 million unique avatars created. Of these 16.8 million, only 941,000 had logged into the virtual world in the last 30 days. 522,000 had logged into the world in the last seven days (Eisenmann and Wagonfeld 3). These findings troubled Linden Labs, who realized after investigation that only 10% of newly registered customers were logging in on a weekly basis after the first three months. Lack of growth was becoming as serious concern, with half the average user registrations happening in 2008 compared to 2007. This data indicates that Second Life had approached the chasm and needed a marketing strategy to gain entry into the mainstream market. Second Life’s usage hours were increasing strongly, but was projected to decrease due to a drop in growth rate.

From the case study analysis by Thomas Eisenmann and Alison Berkley Wagonfield, the authors described the details of Linden Labs application of the Chasm Marketing strategy. In their case study, Linden Labs demonstrated that, with the exception of selecting an appropriate niche market to target, they clearly covered all of the bases in following Moore’s marketing strategy. There was speculation about the appropriate market segmentation to target, however, it does not appear that Linden Labs decided to target their attack to any particular market segmentation. Customer segmentation analysis had never been completed by the company (Eisenmann and Wagonfeld 4), which is a strong indication that their marketing approach did not place a heavy emphasis on following Moore’s niche market targeting approach as prescribed.

Centra Software – eLearning and eMeeting

Centra Software is another example of a company who failed to prescribe to Moore’s Chasm Marketing strategy. In 1997, two years after the company’s creation, Centra’s flagship product, Symposium, was released. Centra was a pioneer in the eMeeting and eLearning marketplace, but quickly was challenged by competitors offering similar products such as WebEx and IBM. Despite the competition, Centra was the market leader for it’s delivery platform product, holding about 50% of the total revenues for the past three years over IBM, Mentergy, and Interwise (Deighton and Poullquen 3).

It was always the goal of Centra Software to become the leading eLearning and eMeeting product provider to Global 2000 corporations. In selecting the appropriate niche market to target for its marketing strategy, Centra Software chose to continue to focus on Global 2000 corporations, with a special emphasis on the top 200 companies within the Global 2000 (Deighton and Poullquen 1). This type of market segmentation failed Centra failed because, unlike Moore’s niche market characterics, Centra’s market segmentation did not make up a vertical industry or market. The Global 2000 is simply a list of the 2000 largest and most successful companies throughout the world. Global 2000 companies cover a wide variety of industries, from oil companies to financial institutions. This resulted in being able to focus in on a market segmentation, however, prevented Centra from creating a unique value proposition that would be strong for a particular vertical market. The result was that Centra’s market segmentation choice was not a traditional fit according to the Chasm Model.

The result of Centra’s choices was that they had to challenge a number of competitors head on with highly competitive companies with on-the-market products competing. Centra also was troubled by their distribution strategy weaknesses and their challenges when making adjustments. WebEx, one of their most serious competitors, was generating nearly all of its sales through telesales (Deighton and Poullquen 3). This approach was working very well for WebEx, and Centra found themselves troubled by their lack of a telesales force. Sales over the telephone would allow Centra to reach Global 2000 corporations quicker and cheaper than its existing field sales force could provide. Despite their best efforts to augment their distribution strategy, Centra’s case study findings showed their distribution strategy was not working smoothly to maximize sales.

According to Paul Gudonis, Centra Software’s President and CEO hired in July 2003, Centra was failing was due to it’s sales force fighting WebEx and Microsoft for the sale of Centra’s product as a general-purpose online meeting solution (“Centra Software: Lessons Learned?”). This explanation provided by Gudonis confirmed that the company had failed to focus their product to address a specific market segment. Centra’s salesforce was attempting to sell their product to a variety of companies with different business processes and different needs. This finding is a clear indicator that Centra Software did not follow the Chasm Model’s prescription to target a market segmentation.

Conclusion

The case studies of Documentum Inc., Linden Labs, and Centra Software all provided an interesting view into the actual implementation of Moore’s marketing strategy into their company’s Go To Market strategy. If Linden Labs and Centra Software’s mistake of selecting an inappropriate market segmentation could have been avoided, the Chasm Model would have probably led to greater adoption of their products by the early majority. Documentum Inc. provided a strong, real world example that the Chasm Model can be highly effective in gaining entry into the mainstream market. From the study of these company’s target market selections and their ultimate level of success, there is sufficient real-world evidence that the Chasm Model is an appropriate marketing strategy for today’s startups looking to offer high tech, discontinuous products.

Bibliography

“Centra Software: Lessons Learned?” Baseline Magazine. Ziff Davis Enterprise. 13 January 2005. Web. 11 December 2009.
“History of Documentum, Inc.” Reference for Business. Web. 6 December 2009. .
Deighton, John, and Laetitia Poullquen. “Centra Software.” Harvard Business School Cases (2002): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Eisenmann, Thomas R., and Alison Berkley Wagonfeld. “Linden Lab: Crossing the Chasm.” Harvard Business School Cases (2009): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Lal, Rajiv, and Sean Lanagan. “Documentum, Inc.” Harvard Business School Cases (2002): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Moore, Geoffrey. “Geoffrey A. Moore on Crossing the Chasm.” April 2002. Web. 7 December 2009.

Software Engineering: a Definition

Software engineering is an engineering discipline that is involved in all aspects of software production, from start to finish (Sommerville, 2004). From the beginning phase of gathering requirements for a software product to the final phase of maintaining software after it’s been released, software engineering is ever present. As an engineering disciple, theories, methodologies, tools, and techniques are defined and used to provide organization and efficiency toward software production. Ultimately, developing software using a software engineer’s approach is done in an effort to meet the goals that today’s technological environment demands.

The Goals of Software Engineering

Software engineering is deeply concerned with providing a means to help development teams meet the expectations of their customers. Today’s companies and customers expect the following (Pressman, 2010):

Software is to be of high quality.

Customers expect that software they use will be reliable and will perform as expected.

Software is produced cost-effectively.

Software development teams are expected to produce software that will meet the expectations of the customer while at the same time staying within their set budget. In the real world, this is easier said than done. Nonetheless, software engineering helps to provide a systematic approach that will allow for better estimation of project costs.

Software is easily maintainable.

Most of us have heard of the term “spaghetti code.” It is definitely possibly to write a program that functions and performs what is required and still be written poorly. Through proper planning and design, development teams can ensure that their software is developed in ways to ensure it’s easily maintainable.

Software is developed in a timely fashion.

The world of technology is changing every day at a rapid pace. Companies rely on utilizing new technologies to enhance productivity and gain a competitive advantage. If software cannot be developed and delivered in a timely fashion, development teams run the risk of their products becoming outdated or cooled down.

The Practice of Software Engineering

Underneath all of the processes, methodologies, and tools within software engineering lies an underlying set of practices that really are at the heart of what the philosophy is behind an engineered approach to software development (Pressman, 2010). Think of the software development process as a problem solving process. The problem is that you have a software product to develop that needs to fulfill a list of requirements specified by your customer. The solution is a completed software product that meets the customer’s requirements. Software engineers use the following four engineering practices to solve the problem: understand the problem, plan a solution, carry out the plan, and examine the result for accuracy. These practices are present in various activities through software engineering process activities.

The Software Process Framework

Through review of all the various software processes that have been developed over the relatively young discipline of software engineering, a generic software process framework has been observed time and time again (Pressman, 2010). Within this framework is a set of framework activities and umbrella activities:

Framework Activities

Communication

It is absolutely essential to communicate and collaborate effectively in any software process. Requirements gathering, a major communication activity, is required to understand what functionality the software requires.

Planning

Planning allows for teams to look at the software project’s present and future paths in an organized manner. Without planning, any development team is destined to be ridden with inefficiency, stress, and an excess of complications.

Modeling

Allows development teams to look at the big picture when designing and developing the software product. Modeling helps in understanding the complexities of today’s modern software.

Construction

Consists of the actual code generation and testing activities. These two activities are generally found in all software development projects, even informal ones.

Deployment

The delivery of software to the customer. Can be either a release version or a partially completed, increment of the software product.

Umbrella Activities

Software project tracking and control

Monitors the progress of the project compared to planned progression. Allows teams to know if they are falling behind schedule so they have opportunities to take action to get caught up.

Risk Management

Allows teams to assess the risks a project faces that may affect the quality or outcome of the project.

Software Quality Assurance

Involves designing a test plan to ensure software meets quality requirements.

Technical reviews

Reviews the work done thus far in a project. The goal of this activity is to ensure that work products are complete before moving on to the next set of work activities.

Measurement

Also known as metrics. Provides information to assist in delivering software that meets the customers needs.

Software Configuration Management

Manages and monitors the effects of changes to through the software process

Reusability Management

Explores the potential for reuse of assets, such as existing code, to help reduce the costs and time of a software project.

Work Product Preparation and Production

Contains a collection of activities used in the development of work products such as models and documentation.

Software Engineering is a Layered Technology

As with all other engineering disciplines, software engineering is committed to delivering quality to the production of a product. A focus on quality is what drives software engineers to improving software engineering processes. This is the reason that a quality focus is the bedrock of software engineering (Pressman 2010).

In an effort to provide quality to a product’s development, processes are the foundation of software engineering. Processes exist as a collection of activities, actions, and tasks that are carried out during the development of a software product. Essentially all of the high-level management and strategies live in this realm.

Software engineering processes make use of methods to carry out the activities of the software development process. Think of methods as the technical know-how to actually carry out the work required to develop software. Communication, testing, requirements gathering, and design modeling are just a few examples of methods that processes use.

Methods in software engineering make use of tools to help with the execution of methods. Many of the tools used by software engineers are, in fact, software based! Communication makes heavy use of email and instant-messaging application. Programmers make use of text editors or integrated development environments. These tools help to provide automation and/or assist the methods with completion of work.

List of Works Cited

Sommerville, Ian. Software Engineering, 7th ed. Pearson Education Limited, Edinburgh Gate 2004.

Pressman, Roger S. Software Engineering: A Practitioner’s Approach, 7th ed. McGraw Hill, New York 2010.