After project scope is defined, WBS is the critical step to bring the project forward. This article will discuss about an overview and comparison of the different WBS approaches and provide my personal experience of developing WBS for the informational systems in an Asian company.
About me:
I worked as an IS (Information systems) developer, SD, SA, and project manager in the information center of Chunghwa telecomm., the biggest telephone company in Taiwan. I was in charge of a number of IS projects, with overlapping schedules. I was also a product manager for Promise Inc., a global storage technology company. As a product manager, I am also handling each product line as an individual project. Through my five years project-related experience, I have adopted several of the WBS approaches mentioned below.
The Overview of the WBS approaches:
The activity-focused WBS approach
This is the most common approach in my company. This approach mainly uses verb and noun. From the conceptual level of project scope, the work is gradually and sequentially divided into separate tasks, which could be managed and accomplished individually. While the top level presents the higher level overview, the bottom level presents the most detail tasks.
The activities clearly describe the “action”, i.e. “what to do”, yet it’d be easy for the project manager to focus too much on the activities and neglect the tangible and measurable deliverables.
The process-focused WBS approach
Instead of focusing on the tasks covered by the project scope, this approach focuses more on the business processes which are required to accomplish the tasks defined in the project scope. Therefore, the deliverables will be analyzed according to each process individually. The combination of all the deliverables from each process will be the final deliverables for the project
The advantage of this approach would be that it clearly depicted how things should be done. The disadvantage is that the analysis of each business process can not tell an overall picture of project activities on a given stage.
The deliverable- focused WBS approach
This approach only uses nouns instead of verbs. Rather than focuses on “what to do”, ti focuses on “what should be done”. In other words, it cares more about the final deliverables instead of the actions leading to the deliverables.
It is a result driven approach, ensuring the deliverables satisfying the project requirements. However, the weakness would be that it’d result in too much focus on the trivial deliverables while neglect the efforts and the complexity of the tasks required to achieve the deliverables.
The outcome-focused WBS approach
This approach focuses on the outcome, i.e. the desirable effect resulted from the activities. Based on the target outcome, the required tasks and activities are planned. The strength of this approach is that it directly targets at the desired effect; the weakness of this approach is that the “desired effect” is usually hard to define and measure. It’s not easy to tell what tasks could result in the desirable result.
During the work in the IS development, we adopted the activity focused approach mostly in accordance with the Top-down SDLC we applied, since we almost built every individual IS from scratch. It clearly expressed the conceptual views at different levels, which is also convent for a project manager to present to different stakeholders’.
However, during my term working as a dedicated OEM product manager, most of our OEM products are customized from channel products. Therefore, most projects could refer to other similar projects. As a result, instead of conducting top-down activity focused approach, I mostly adopted the deliverables-focused approach in that most of the deliverables have been finalized in other projects and the customization would only change few of the deliverables.
To sum up, different approaches could be applied for different focus of the projects. However, the ideal recommendation would be to utilize more than one approach for the WBS in that the comparison of different approaches would compensate the weakness of each other and help project manager to prevent the negligence.
Tuesday, November 4, 2008
Monday, November 3, 2008
Typical IT Project Management Pitfalls
The survey by Standish group revealed that only 29% of IT projects achieved success over the last 20 years. Experienced project managers, Project organisation and researchers have attempted to trap the essence of what is behind these failures and have found the factors discussed below with the impact of each factor:
Lack of the right resources with the right skills
Any project however good planned is doomed to fail without right resources with the right skills. Researchers have found this factor the cause of most of the project failures still this is the most common mistake that most organisations make. "All the planning in the world won't overcome an insufficiency of talent" says Joel Koppelman, CEO of project management software vendor Primavera.
Lack of experienced project manager
This factor may bring the project in a zone where it is almost impossible to take it in control. Once in this zone, even the best project manager may feel difficulties. The solution to this problem is to hire the competent project manager.
Not following a standard, repeatable project management process
Lack of methodology increases the risk of falling of tasks related to the project through the cracks. This also increases the risk of reworking and thus meeting the deadlines in terms of time and costs.
IT gets hamstrung by too much process
When there are too much of processes to be followed by team, the teams become inflexible and their inflexibility frustrates stakeholders, which leads to communication gaps and further delays in the project completions.
Poor definition of the scope and not tracking changes to the scope of the project
If a project's scope isn't well-defined by the business and IT up front and When the changes to the scope are not tracked through organised structure and changes are incorporated without any analysed, the project keeps on growing in every aspect i.e. complexity, cost, time line etc. and ultimately reaches the stage of its fall before the completion.
Lack of up-to-date data about the status of projects
Anything that cannot be measured cannot be managed. For managing anything, we need to know the status of process i.e. whether it is in control or moving out of its ranges and only measurement can provide this information.
Lack of analysis of dependencies between projects
There are often dependencies on other projects going on at the same time. When project managers fail to see the dependencies between projects-such as staff assigned to one project are needed on another, projects get held up. Such slowdowns can have a ripple effect on all projects.
Unreasonable deadlines
IT sets itself up to fail and gets a reputation for not being able to deliver projects on time. We have seen this in the case discussed in class that how Mike, the project manager tried to accommodate the project deadlines set by the Board members. But tampering with dependencies and the plan only creates even more problems thus delivering the project on time even more difficult
Incomplete Project Schedules
The factor creates the chaos in the whole process of project execution. Team members don't know what is due when, which makes completing the project on time a challenge.
Lack of Communication with project sponsors and stakeholders:
This factor creates a kind of misunderstanding about the deliverables and ultimately leads to the failure of project. A project is considered successful if it meets the requirements of the stakeholders and end users.
References: http://www.itbusiness.ca/it/client/en/Home/News.asp?id=49310
Lack of the right resources with the right skills
Any project however good planned is doomed to fail without right resources with the right skills. Researchers have found this factor the cause of most of the project failures still this is the most common mistake that most organisations make. "All the planning in the world won't overcome an insufficiency of talent" says Joel Koppelman, CEO of project management software vendor Primavera.
Lack of experienced project manager
This factor may bring the project in a zone where it is almost impossible to take it in control. Once in this zone, even the best project manager may feel difficulties. The solution to this problem is to hire the competent project manager.
Not following a standard, repeatable project management process
Lack of methodology increases the risk of falling of tasks related to the project through the cracks. This also increases the risk of reworking and thus meeting the deadlines in terms of time and costs.
IT gets hamstrung by too much process
When there are too much of processes to be followed by team, the teams become inflexible and their inflexibility frustrates stakeholders, which leads to communication gaps and further delays in the project completions.
Poor definition of the scope and not tracking changes to the scope of the project
If a project's scope isn't well-defined by the business and IT up front and When the changes to the scope are not tracked through organised structure and changes are incorporated without any analysed, the project keeps on growing in every aspect i.e. complexity, cost, time line etc. and ultimately reaches the stage of its fall before the completion.
Lack of up-to-date data about the status of projects
Anything that cannot be measured cannot be managed. For managing anything, we need to know the status of process i.e. whether it is in control or moving out of its ranges and only measurement can provide this information.
Lack of analysis of dependencies between projects
There are often dependencies on other projects going on at the same time. When project managers fail to see the dependencies between projects-such as staff assigned to one project are needed on another, projects get held up. Such slowdowns can have a ripple effect on all projects.
Unreasonable deadlines
IT sets itself up to fail and gets a reputation for not being able to deliver projects on time. We have seen this in the case discussed in class that how Mike, the project manager tried to accommodate the project deadlines set by the Board members. But tampering with dependencies and the plan only creates even more problems thus delivering the project on time even more difficult
Incomplete Project Schedules
The factor creates the chaos in the whole process of project execution. Team members don't know what is due when, which makes completing the project on time a challenge.
Lack of Communication with project sponsors and stakeholders:
This factor creates a kind of misunderstanding about the deliverables and ultimately leads to the failure of project. A project is considered successful if it meets the requirements of the stakeholders and end users.
References: http://www.itbusiness.ca/it/client/en/Home/News.asp?id=49310
PM at The City of X
Having completed a Computer Science degree, you’d think they might have covered project management skills. However that is not the case, as the work consisted mostly of algorithms, encryption (yuck!), and other nerdy things. Therefore when I began my career at The City of X (municipal government) post-graduation, I knew nothing about PM; so much so that it could have hit me over the head and I wouldn’t have noticed.
Shortly after commencing work, I was assigned to a team that was tasked with rolling out the newest version of the ERP system in use, JDEdwards, and was struck by all the planning and meetings that went on. Was it really necessary to meet once a week, just to talk about how things were going? Not to mention the monthly meetings where they invited everyone and Prime Minister. And what about all this documentation? It really seemed like they were trying to make more work for people! Do we really need all these signatures to make a change? At the time I thought, ‘cannot they not just tell us what do to and go away for two months while we do it?’ There was also the issue of the steering committee, which at the time seemed like a bunch of talking heads whose role was to check in on each other for comfort’s sake. What a bunch of bureaucratic fluff.
Flash forward eight years; was I ever wrong. What had seemed to me at the time like a lot of wasted time and effort was in fact the flawless execution of project management procedures and skill. My ill-informed perspective was unable to see the value of all those meetings, documentation, and communication. I naively assumed that all projects ran that smoothly, even in the absence of all that ‘extra’ work we were tasked with. In reality, those procedures led to successful projects; time after time. Communication was effective and structured, everyone knew their tasks and expectations, and issues or concerns were communicated immediately to the appropriate individuals. The PM procedures delivered IT value to both internal customers and taxpayers; ensuring that large projects ran smoothly, on-time, and on-budget.
Shortly after commencing work, I was assigned to a team that was tasked with rolling out the newest version of the ERP system in use, JDEdwards, and was struck by all the planning and meetings that went on. Was it really necessary to meet once a week, just to talk about how things were going? Not to mention the monthly meetings where they invited everyone and Prime Minister. And what about all this documentation? It really seemed like they were trying to make more work for people! Do we really need all these signatures to make a change? At the time I thought, ‘cannot they not just tell us what do to and go away for two months while we do it?’ There was also the issue of the steering committee, which at the time seemed like a bunch of talking heads whose role was to check in on each other for comfort’s sake. What a bunch of bureaucratic fluff.
Flash forward eight years; was I ever wrong. What had seemed to me at the time like a lot of wasted time and effort was in fact the flawless execution of project management procedures and skill. My ill-informed perspective was unable to see the value of all those meetings, documentation, and communication. I naively assumed that all projects ran that smoothly, even in the absence of all that ‘extra’ work we were tasked with. In reality, those procedures led to successful projects; time after time. Communication was effective and structured, everyone knew their tasks and expectations, and issues or concerns were communicated immediately to the appropriate individuals. The PM procedures delivered IT value to both internal customers and taxpayers; ensuring that large projects ran smoothly, on-time, and on-budget.
McDonalds’ “Innovate Project” failure
McDonalds’ “Innovate Project” failure
Most companies don’t like to reveal their failures of IT project management, but they would learn an important lesson by analyzing their project failures.
History
“Innovate Project” was one of the most expensive and extensive information technology projects. This project aimed to create a real-time global network to link over thirty thousand stores in 121 countries to headquarter by Intranet. This system would collect real time information from every store and then deliver it to the headquarters’ executives.
This information would enable headquarters’ store manager and executives to effectively and consistently manage and operate their stores moment by moment.
Innovate project started in 1999 with a budget of $1 billion and a five-year plant. In late 2002, McDonald's cancelled Innovate. The $170 million that had already been spent for the Innovate project was lost and between 100 and 200 contractors and McDonald's employees working on the project might be dismissed or reassigned.
Mistakes and comments
Scope Management
In the stage of initial analysis, the project management might not carefully consider whether or not the project had the right scope and the project could address the current issues.
Establishing a real time global network to cover all locations was impossible from the beginning, because individual countries had different IT infrastructures.
Project scope should have been defined more in detail to identify viability of project.
Stakeholder Involvement
To identify project feasibility and define its scope, sufficient information and feedback from store managers in each country should have been given. Project team should have identified whether or not they could address current challenges through the feedback.
Project Manager
It’s very important to have a qualified and experienced project manager in the project such as this. If a company had had a skilled project manager, project manager would have told executives that Innovate Project was impossible, illustrating the need to examine the project feasibility thoroughly from the beginning.
Executives Understanding
They understood the importance of Innovate Project to improve daily operation management but did not have sufficient understanding of IT technology and had unrealistic expectations...
Conclusion
The failure of McDonalds’ Innovate Project clearly illustrates that project scope management is necessary to complete the project successfully. Project team and executives should have sufficient understanding of the project and its scope should be well-defined in order to deliver a valuable product within the expected time frame and budget.
Reference:McDonalds: McBusted–‘TURNS AND RETURNS’ by Larry Barrett, retrieved October 31, 2008 from baseline website: http://www.baselinemag.com/c/a/Projects-Supply-Chain/McDonalds-McBusted/3/
Most companies don’t like to reveal their failures of IT project management, but they would learn an important lesson by analyzing their project failures.
History
“Innovate Project” was one of the most expensive and extensive information technology projects. This project aimed to create a real-time global network to link over thirty thousand stores in 121 countries to headquarter by Intranet. This system would collect real time information from every store and then deliver it to the headquarters’ executives.
This information would enable headquarters’ store manager and executives to effectively and consistently manage and operate their stores moment by moment.
Innovate project started in 1999 with a budget of $1 billion and a five-year plant. In late 2002, McDonald's cancelled Innovate. The $170 million that had already been spent for the Innovate project was lost and between 100 and 200 contractors and McDonald's employees working on the project might be dismissed or reassigned.
Mistakes and comments
Scope Management
In the stage of initial analysis, the project management might not carefully consider whether or not the project had the right scope and the project could address the current issues.
Establishing a real time global network to cover all locations was impossible from the beginning, because individual countries had different IT infrastructures.
Project scope should have been defined more in detail to identify viability of project.
Stakeholder Involvement
To identify project feasibility and define its scope, sufficient information and feedback from store managers in each country should have been given. Project team should have identified whether or not they could address current challenges through the feedback.
Project Manager
It’s very important to have a qualified and experienced project manager in the project such as this. If a company had had a skilled project manager, project manager would have told executives that Innovate Project was impossible, illustrating the need to examine the project feasibility thoroughly from the beginning.
Executives Understanding
They understood the importance of Innovate Project to improve daily operation management but did not have sufficient understanding of IT technology and had unrealistic expectations...
Conclusion
The failure of McDonalds’ Innovate Project clearly illustrates that project scope management is necessary to complete the project successfully. Project team and executives should have sufficient understanding of the project and its scope should be well-defined in order to deliver a valuable product within the expected time frame and budget.
Reference:McDonalds: McBusted–‘TURNS AND RETURNS’ by Larry Barrett, retrieved October 31, 2008 from baseline website: http://www.baselinemag.com/c/a/Projects-Supply-Chain/McDonalds-McBusted/3/
Summary of the AT&T Self Destructive Upgrade Project
Since November 23, 2003, under Federal Commission rule, customers of a certain carrier have the rights to keep their original phone numbers even if they switch to another carrier. Under this external complication, the already problematic upgrade project of AT&T’s CRM system collapsed which cost loss in revenue, loss of customer to its competitors, loss of reputation and high turnover (layoffs). As one of the older phone service carriers, AT&T has slipped from being the market leader to a second ranked carrier with market share dropping of 25% to 17% from 2003 to 2001. To catch up with their competitors, AT&T started to upgrade its phone network that can not handle data transfer through phone to a new network-global system for mobile communication or a GMS that added capacity to global compatibility to overseas providers. However, the transition was not well accepted by customers. To improve not only the quality of customer service, but also the efficiency of customer service representatives, AT&T started to upgrade its complicated CRM (Siebel) to a highly customized Siebel version 6 with software that has an integration tool holding the systems together. This Siebel 6 still could not meet all customer representatives’ expectations. In spring of 2003, they started the project called “Odyssey” to move over to the new GMS and Siebel 7.5 that they were developing. This upgrade project, involving roughly 15 systems, had a bad beginning. Changing the system to web based was a complex and large scope project because it required ripping off all the links which were established in Siebel 6. Creating each new link would require at least 20 or more people to write up. Another problem was that each team worked independently. Sometimes one team would finish testing a part but would find the code of some other parts changed. Also, there was rumour of outsourcing and future layoff that lowered the morale of employees leading to low productivity. Staffs even looked for other jobs during the project. A new project manager had replaced the former CIO which intensified problems employees were having. AT&T should understand that for such a complex project to succeed, they should have a flexible schedule and a back up plan while there was the portability requirement on Nov 23, 2003. Also, the portability required AT&T to work on system that integrated with other carries. Other top carriers decided to employ TSI Communication. However, AT&T chose NeuStar before the announcement of other carriers’ decision. This resulted in an integration problem later on when TSI modified its system and NeuStar could no longer communicate with the TSI. The complexity of the project, abandonment of some testing, confirmation of the layoff, outsourcing rumour, the inflexible schedule and complication of portability issues led to the failure of the project. The failure of upgrade project and the problem of NeuStar integrating with other carriers caused the company to lose 50000 customers per week and an estimated loss of revenue of $100 million because of the lack of service. Finally, AT&T undersold itself to Cingular at $41 billion.
By Cheuk Ho
By Cheuk Ho
Experience with a runaway project
Most of the projects fail either because they are – a) Not able to finish in time, b) Are cost overrun, c) Are below client expectation.
I would like to analyse the only project failure that I have experienced in my previous company in India that provides technical solutions to major financial institutions worldwide. The company has a flagship banking product in its name along with major clients across globe and has repute for delivering zero defect solutions. One of the existing clients came up with the need for a system, similar to CRM systems that are getting widely implemented, that would help them in assessing and fulfilling mortgage requirements of emerging corporate with an inbuilt feature to verify collaterals requirement for the given loan amount. This story is pretty interesting and unique because this project had consecutive failures at various phases but was never discontinued or acknowledged as a failed project. Let me divide the project into phase1 which was the first time the project started and phase 2&3 when the project went to a different vendor after initial failure and came back to the original vendor after second time failure.
Phase1: The project was first started following standard project management methodologies, however at a later stage scope creep resulted in a disaster. The requirements were not clear, nor were the scope or associated risk. Client changed the requirement frequently, the deliverable deadline slipped, people lost motivation and the final deliverable had a quality that was far below acceptable limit. This resulted in the project to be lost by my company to one of the competitors. The project team was penalised for under performance by giving no hike for that year, at a time of tech bubble when rewards used to be huge. There was frustration in the company from top management to bottom as this was the first time in the company history that a project resulted in an unhappy client. This meant loss of future business with this client and a poor brand image for the company.
Phase 2&3: This project went to the competition, but the executive team from the client side remained the same. The same level of uncertainty in requirements led to a second time failure of the project. This gave an opportunity to my company to cover up for the past mistake and try to win client’s faith. The business development team approached the client with the goal of getting the project back to the company anyhow. This meant making unrealistic commitment about the deliverable timeline of eight months (6 days a week, 10 hours a day) , cutting down on the budget by 80% and committing to deliver the design for the next phase of the project for free. A top level management planning team decided that all the members from the old team who worked on the project earlier will be pulled into this project since they knew the system better and this meant lesser time for learning curve. Those team members felt that they got a chance to prove their worth. This project was a bundled project where the budget was fixed. Adding extra resources meant loss to the company. Despite that a team was formed with 75 people that included design, development, testing and management. The group head was involved in weekly meetings of the project and the CEO had been tracking the progress of the project. The high level involvement reflected the criticality of the project for the company.
Though the project was executed following standard infrastructure, good communications, with proper project management tools by adhering to key roles; it did not succeed due to poor estimation of budget, time and scope assessment. The management tried to follow best practices and also covered up for the mistakes done earlier. However they failed to realize that employee motivation was an important aspect of project success. The project failed on various dimensions of time, cost, client dissatisfaction and low morale of employees. It was a runaway project which kept on taking resources for three years and was ultimately dumped because the management finally realised that the existing technology could not support the project need. My company did not make any profit on this project. It simply helped them in getting their records clean with the client who finally walked away by accepting the deliverable as one with agreed upon quality and expectation. We however came to know that the project was never implemented at the client’s site because they realised that in three years their requirement had changed significantly and there was no way they could live with the technology that was getting obsolete and would lack support from Microsoft in future.
I would like to analyse the only project failure that I have experienced in my previous company in India that provides technical solutions to major financial institutions worldwide. The company has a flagship banking product in its name along with major clients across globe and has repute for delivering zero defect solutions. One of the existing clients came up with the need for a system, similar to CRM systems that are getting widely implemented, that would help them in assessing and fulfilling mortgage requirements of emerging corporate with an inbuilt feature to verify collaterals requirement for the given loan amount. This story is pretty interesting and unique because this project had consecutive failures at various phases but was never discontinued or acknowledged as a failed project. Let me divide the project into phase1 which was the first time the project started and phase 2&3 when the project went to a different vendor after initial failure and came back to the original vendor after second time failure.
Phase1: The project was first started following standard project management methodologies, however at a later stage scope creep resulted in a disaster. The requirements were not clear, nor were the scope or associated risk. Client changed the requirement frequently, the deliverable deadline slipped, people lost motivation and the final deliverable had a quality that was far below acceptable limit. This resulted in the project to be lost by my company to one of the competitors. The project team was penalised for under performance by giving no hike for that year, at a time of tech bubble when rewards used to be huge. There was frustration in the company from top management to bottom as this was the first time in the company history that a project resulted in an unhappy client. This meant loss of future business with this client and a poor brand image for the company.
Phase 2&3: This project went to the competition, but the executive team from the client side remained the same. The same level of uncertainty in requirements led to a second time failure of the project. This gave an opportunity to my company to cover up for the past mistake and try to win client’s faith. The business development team approached the client with the goal of getting the project back to the company anyhow. This meant making unrealistic commitment about the deliverable timeline of eight months (6 days a week, 10 hours a day) , cutting down on the budget by 80% and committing to deliver the design for the next phase of the project for free. A top level management planning team decided that all the members from the old team who worked on the project earlier will be pulled into this project since they knew the system better and this meant lesser time for learning curve. Those team members felt that they got a chance to prove their worth. This project was a bundled project where the budget was fixed. Adding extra resources meant loss to the company. Despite that a team was formed with 75 people that included design, development, testing and management. The group head was involved in weekly meetings of the project and the CEO had been tracking the progress of the project. The high level involvement reflected the criticality of the project for the company.
Though the project was executed following standard infrastructure, good communications, with proper project management tools by adhering to key roles; it did not succeed due to poor estimation of budget, time and scope assessment. The management tried to follow best practices and also covered up for the mistakes done earlier. However they failed to realize that employee motivation was an important aspect of project success. The project failed on various dimensions of time, cost, client dissatisfaction and low morale of employees. It was a runaway project which kept on taking resources for three years and was ultimately dumped because the management finally realised that the existing technology could not support the project need. My company did not make any profit on this project. It simply helped them in getting their records clean with the client who finally walked away by accepting the deliverable as one with agreed upon quality and expectation. We however came to know that the project was never implemented at the client’s site because they realised that in three years their requirement had changed significantly and there was no way they could live with the technology that was getting obsolete and would lack support from Microsoft in future.
Role of marketing in project management for consumer software
As we all know, one of the key components of successful project management practice, whether for enterprise software or else, is the inclusion of the end-user into the design process. Projects that neglect this component often end up with products that fail to meet the desired functionality criteria and suffer from low adoption rates, if not get rejected as failed projects altogether.
An industry held back by project management
This holds especially true for consumer software. The examples I will use are from my favourite industry: video games. The design process of a game, which you can think of as consumer entertainment software, is fairly complicated. From the conception of a game idea to the end product, there is a long process with many tough decisions to be made about the final characteristics of the game. Project managers go through this long decision tree with the ultimate goal of making choices that will resonate most with the end users. Ironically though, most of the time they have to make these decisions without actually consulting with the end users. The role of traditional marketing in the industry is somewhat limited to focus group studies and beta tests of limited sample sizes. Given the length and complication of the typical project, however, it is very easy to misinterpret these limited directions over time, or to forget them altogether.
It is entirely for this reason that many games turn out to be commercial flops. At best such disconnection with the end-user needs results in a product that cannot sell itself to the consumer. Advertising and push marketing are typically employed to push sales, while advertisement spending reduces the ROI for the project. The perfect example to this situation is the biggest player in the market: Electronic Arts. It has been announced by the company very recently that they would lay off some 600 employees after millions of loss incurred, despite an increase in revenues. Obviously, someone has been doing something wrong.
A surprising example of best practice
Taleworlds is an independent video game developer of very recent fame. They owe their fame to the success of their game Mount & Blade. The remarkable thing about this game is that the development team consisted of only two people, Armagan Yavuz and Ipek Yavuz, and this game was their first ever project. Working with a shoestring budget and zero advertising, they achieved sales of 40,000 units from their own website, and their future sales potential is forecast to be around half a million units after they have been picked up by a well known publisher. In an industry where so many games with million dollar budgets and huge development teams with top notch talent nosedive in sales, their rate of success is unheard of.
They owe their success to their inclusion of end users into the design process. Their unique business model allowed them to start selling the game even as it was in pre-alpha stage, with the catch that purchasers would get all the future updates for free. Furthermore, they established an online community where the users could have a direct dialogue with the designers, and the end-user ideas could go directly into the game without any mediation. New ideas from the design team also got immediate feedback from the customers. The end result was a game with nothing but truly valued added features. Still some people in the industry cannot quite understand why a game that seemingly lacks graphical bells and whistles can sell this well. The answer is that they found the right bells and whistles that mattered to the end user, not to the gut sense of the project management team. Compared to the industry average, their ROI is staggering, all for this little detail in project management philosophy.
By Taylan Kadayifcioglu
An industry held back by project management
This holds especially true for consumer software. The examples I will use are from my favourite industry: video games. The design process of a game, which you can think of as consumer entertainment software, is fairly complicated. From the conception of a game idea to the end product, there is a long process with many tough decisions to be made about the final characteristics of the game. Project managers go through this long decision tree with the ultimate goal of making choices that will resonate most with the end users. Ironically though, most of the time they have to make these decisions without actually consulting with the end users. The role of traditional marketing in the industry is somewhat limited to focus group studies and beta tests of limited sample sizes. Given the length and complication of the typical project, however, it is very easy to misinterpret these limited directions over time, or to forget them altogether.
It is entirely for this reason that many games turn out to be commercial flops. At best such disconnection with the end-user needs results in a product that cannot sell itself to the consumer. Advertising and push marketing are typically employed to push sales, while advertisement spending reduces the ROI for the project. The perfect example to this situation is the biggest player in the market: Electronic Arts. It has been announced by the company very recently that they would lay off some 600 employees after millions of loss incurred, despite an increase in revenues. Obviously, someone has been doing something wrong.
A surprising example of best practice
Taleworlds is an independent video game developer of very recent fame. They owe their fame to the success of their game Mount & Blade. The remarkable thing about this game is that the development team consisted of only two people, Armagan Yavuz and Ipek Yavuz, and this game was their first ever project. Working with a shoestring budget and zero advertising, they achieved sales of 40,000 units from their own website, and their future sales potential is forecast to be around half a million units after they have been picked up by a well known publisher. In an industry where so many games with million dollar budgets and huge development teams with top notch talent nosedive in sales, their rate of success is unheard of.
They owe their success to their inclusion of end users into the design process. Their unique business model allowed them to start selling the game even as it was in pre-alpha stage, with the catch that purchasers would get all the future updates for free. Furthermore, they established an online community where the users could have a direct dialogue with the designers, and the end-user ideas could go directly into the game without any mediation. New ideas from the design team also got immediate feedback from the customers. The end result was a game with nothing but truly valued added features. Still some people in the industry cannot quite understand why a game that seemingly lacks graphical bells and whistles can sell this well. The answer is that they found the right bells and whistles that mattered to the end user, not to the gut sense of the project management team. Compared to the industry average, their ROI is staggering, all for this little detail in project management philosophy.
By Taylan Kadayifcioglu
Subscribe to:
Posts (Atom)
Posts
