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
Comparing Microsoft Project to Web-Based Project Management Software
“If you are benchmarking or comparing Microsoft Project to newer web-based project management software, here are 3 key factors to consider when reviewing this type of project management software.
1. Difference in Philosophy:
Microsoft Project’s philosophy keeps the traditional project management paradigm but patches the tool with collaborative features. It has many robust project planning and resource allocation tools. However, it is very much a project manager’s tool. It is geared towards people with training both in project management methods and in using Microsoft Project PM Software itself.
A good example of this is that the collaborative features in the software are not real-time. Information needs to be pro-actively published either by the project manager out to the team or from team members back to the project manager. Practically speaking, the project manager and team members work on their local copies of MS Project and then submit or publish their work to the server.
This adds in an additional layer of adoption and is an extra task that managers and team members need to manage on a project. It does add in some collaboration to the information flow of project management but it reduces some of the benefit of having collaborative project management software by adding a barrier to the flow of information (and it creates more work).
2. Multiple Components:
Microsoft does not offer Microsoft Project as an ASP or Software as a Service model. To use Microsoft Project PM Software a company needs to buy multiple components and host it themselves. These components include desktop copies of the software, a copy of the server software, non-project manager licenses, Microsoft SharePoint Server software and MS Windows Server software.
Project management software like Vertabase Pro, which is native web-based software, can be purchased on an ASP (also called On-Demand project management software or Software as a Service - SaaS). Licenses to use the software are purchased on an annual basis and it runs on any browser or operating system. That means the project management software can work on Mac OS or Windows operating system. It can work using Microsoft Internet Explorer, Apple’s Safari browser or even Mozilla Firefox. Further, there are no additional components to buy or install.
3. Training and Support:
Training and support must be purchased separately for Microsoft Project PM Software. In many cases, training for Microsoft Project can cost thousands and thousands of dollars. Since the software is designed for more experienced or professionally trained project managers, the training is important for people to get the most out of the project management system. If people don’t get trained properly or if there is not a culture or politics enforcing use of the project management tool, the tool can quickly fall into disuse.
Support is a la carte with Microsoft Project Server. It needs to be purchased separately or on a per-incident basis. Support calls for Microsoft Project PM Software are often handled much like other customer support calls from larger software vendors.
Training and support are included with every purchase of Vertabase Pro PM Software, as it is with other web-based project management tools. In some cases, the tools are so intuitive that training is not even needed. Some software, like Vertabase Pro, also includes videos on using the PM software and extensive online help files to get the most out of the application.”
Post by Marcos Souza
_____________________________________________________
Reference: Phillips, Mark - Comparing Microsoft Project to Web-Based Project Management Software – The Vertabase Blog – October 1st 2006
1. Difference in Philosophy:
Microsoft Project’s philosophy keeps the traditional project management paradigm but patches the tool with collaborative features. It has many robust project planning and resource allocation tools. However, it is very much a project manager’s tool. It is geared towards people with training both in project management methods and in using Microsoft Project PM Software itself.
A good example of this is that the collaborative features in the software are not real-time. Information needs to be pro-actively published either by the project manager out to the team or from team members back to the project manager. Practically speaking, the project manager and team members work on their local copies of MS Project and then submit or publish their work to the server.
This adds in an additional layer of adoption and is an extra task that managers and team members need to manage on a project. It does add in some collaboration to the information flow of project management but it reduces some of the benefit of having collaborative project management software by adding a barrier to the flow of information (and it creates more work).
2. Multiple Components:
Microsoft does not offer Microsoft Project as an ASP or Software as a Service model. To use Microsoft Project PM Software a company needs to buy multiple components and host it themselves. These components include desktop copies of the software, a copy of the server software, non-project manager licenses, Microsoft SharePoint Server software and MS Windows Server software.
Project management software like Vertabase Pro, which is native web-based software, can be purchased on an ASP (also called On-Demand project management software or Software as a Service - SaaS). Licenses to use the software are purchased on an annual basis and it runs on any browser or operating system. That means the project management software can work on Mac OS or Windows operating system. It can work using Microsoft Internet Explorer, Apple’s Safari browser or even Mozilla Firefox. Further, there are no additional components to buy or install.
3. Training and Support:
Training and support must be purchased separately for Microsoft Project PM Software. In many cases, training for Microsoft Project can cost thousands and thousands of dollars. Since the software is designed for more experienced or professionally trained project managers, the training is important for people to get the most out of the project management system. If people don’t get trained properly or if there is not a culture or politics enforcing use of the project management tool, the tool can quickly fall into disuse.
Support is a la carte with Microsoft Project Server. It needs to be purchased separately or on a per-incident basis. Support calls for Microsoft Project PM Software are often handled much like other customer support calls from larger software vendors.
Training and support are included with every purchase of Vertabase Pro PM Software, as it is with other web-based project management tools. In some cases, the tools are so intuitive that training is not even needed. Some software, like Vertabase Pro, also includes videos on using the PM software and extensive online help files to get the most out of the application.”
Post by Marcos Souza
_____________________________________________________
Reference: Phillips, Mark - Comparing Microsoft Project to Web-Based Project Management Software – The Vertabase Blog – October 1st 2006
The world’s next “biggest IT project disaster”
In 2002 the UK government announced a project to build a new computer system for the National Health Service (NHS). Completion was due in 2012 and the original budget set at £12.4 billion. By the middle of 2004, contracts totalling £6.2 billion had been awarded to the following IT companies; Accenture, CSC, Fujitsu, BT, IDX and iSoft – but since then progress has been limited.
The NHS delivers state funded comprehensive healthcare to 60 million people and is Europe’s largest employer, thus a new computer system is no small project. The plan is to replace all existing computers with a system that securely stores data centrally and provides comprehensive medical records that can be accessed anywhere.
Despite recent claims that the project has made substantial progress, latest estimates suggest the cost will now be £20 billion, or an astounding $35 billion! The project is currently running four years behind schedule and has no firm date for going live, although this will now be well into the next decade.
In 2007 a lead Fujitsu consultant stated that there was a danger of the contract delivering a “camel rather than a racehorse”, that the project “lacked visionary leadership” and that the techniques being used were those “familiar for small projects” and that they were simply not working.
The Road Thus Far Travelled
The project lost its first CEO, Richard Granger, who resigned from his $500,000 pa role in 2007, and two of the worlds biggest IT and consultancy firms have also pulled out. Most high profile was the withdrawal of Accenture as lead supplier, who proved that the risks of high profile failure can be so great that firms turn down potentially very profitable work. The second and latest firm to pull out, due to failed attempts to “reset” their contract, is the aforementioned Fujitsu, who earned £256 million from the project in 2006/07 and the decision to withdraw, will cost them an estimated £340 million.
The project appears to be heading for failure, and this raises several questions. Why is it still ongoing? Why, given the statistics of the success of big projects, was it conceived in the first place? And is it possible for a big project to be successful using existing project management techniques?
By Martin Berry
References
NHS computer project will cost £12.4bn
http://www.computing.co.uk/computing/news/2158476/nhs-computer-project-cost-4bn
Boss of troubled £12bn NHS computer project quits
http://www.timesonline.co.uk/tol/news/uk/health/article1942900.ece
NHS computer project troubled by more delays
http://www.timesonline.co.uk/tol/life_and_style/health/article4029206.ece
Bank bailout puts £12.7bn NHS computer project in jeopardy
http://www.guardian.co.uk/society/2008/oct/29/nhs-health
Delays to NHS computer system could cost taxpayers £40bn
http://www.guardian.co.uk/politics/2006/oct/01/1
NHS Computer Project Failing
http://www.lightbluetouchpaper.org/2007/09/13/nhs-computer-project-failing/
£12bn NHS computer upgrade faces fresh turmoil
http://www.independent.co.uk/news/business/analysis-and-features/16312bn-nhs-computer-upgrade-faces-fresh-turmoil-418040.html
£20bn NHS computer system 'doomed to fail'
http://www.telegraph.co.uk/news/uknews/1542486/andpound20bn-NHS-computer-system-%27doomed-to-fail%27.html
The NHS delivers state funded comprehensive healthcare to 60 million people and is Europe’s largest employer, thus a new computer system is no small project. The plan is to replace all existing computers with a system that securely stores data centrally and provides comprehensive medical records that can be accessed anywhere.
Despite recent claims that the project has made substantial progress, latest estimates suggest the cost will now be £20 billion, or an astounding $35 billion! The project is currently running four years behind schedule and has no firm date for going live, although this will now be well into the next decade.
In 2007 a lead Fujitsu consultant stated that there was a danger of the contract delivering a “camel rather than a racehorse”, that the project “lacked visionary leadership” and that the techniques being used were those “familiar for small projects” and that they were simply not working.
The Road Thus Far Travelled
The project lost its first CEO, Richard Granger, who resigned from his $500,000 pa role in 2007, and two of the worlds biggest IT and consultancy firms have also pulled out. Most high profile was the withdrawal of Accenture as lead supplier, who proved that the risks of high profile failure can be so great that firms turn down potentially very profitable work. The second and latest firm to pull out, due to failed attempts to “reset” their contract, is the aforementioned Fujitsu, who earned £256 million from the project in 2006/07 and the decision to withdraw, will cost them an estimated £340 million.
The project appears to be heading for failure, and this raises several questions. Why is it still ongoing? Why, given the statistics of the success of big projects, was it conceived in the first place? And is it possible for a big project to be successful using existing project management techniques?
By Martin Berry
References
NHS computer project will cost £12.4bn
http://www.computing.co.uk/computing/news/2158476/nhs-computer-project-cost-4bn
Boss of troubled £12bn NHS computer project quits
http://www.timesonline.co.uk/tol/news/uk/health/article1942900.ece
NHS computer project troubled by more delays
http://www.timesonline.co.uk/tol/life_and_style/health/article4029206.ece
Bank bailout puts £12.7bn NHS computer project in jeopardy
http://www.guardian.co.uk/society/2008/oct/29/nhs-health
Delays to NHS computer system could cost taxpayers £40bn
http://www.guardian.co.uk/politics/2006/oct/01/1
NHS Computer Project Failing
http://www.lightbluetouchpaper.org/2007/09/13/nhs-computer-project-failing/
£12bn NHS computer upgrade faces fresh turmoil
http://www.independent.co.uk/news/business/analysis-and-features/16312bn-nhs-computer-upgrade-faces-fresh-turmoil-418040.html
£20bn NHS computer system 'doomed to fail'
http://www.telegraph.co.uk/news/uknews/1542486/andpound20bn-NHS-computer-system-%27doomed-to-fail%27.html
Importance of a Project Plan
Project Plan is a document used by the project managers as a guide to project execution and control. Project plan is primarily used to document the assumptions and decisions that facilitate communication among stake holders, project budget, scope and schedule. A project plan should answer following questions
a. What is the problem that project plan is trying to address?
b. What are the major project deliverables?
c. Who will be involved and what would be their responsibilities?
d. What is the project timeline and what are individual milestones?
This document outlines five simple steps to create a project plan which can act as a checklist and prevent project managers from taking wrong path.
Step 1: Create a task list and Work Breakdown Structure
Project manager often underestimates the total time duration and total number of tasks involved. A good project manager would create a WBS – a Hierarchical list of the project phases, tasks and milestones. A good manager will be able to identify all the phases of the project. WBS is critical because its drives the scope of the project. By properly mapping WBS to individual steps will avoid rework and false starts.
1. Identify the major pieces of the project.
2. Break down the major piece to the smallest individual piece.
3. Identify individual milestones, completion points – at the end of each of the major activity to help measure project progress and for bench marking.
4. It is also important to give names for individual milestones.
Step 2: Indent or Outdent tasks to finalize the WBS
Once the project is broken down into tasks, project manager should prioritize each task. A good task list would differentiate major phases of work called summary tasks and the smaller phases of work called sub tasks. Summary Tasks have sub tasks indented underneath them. Subtasks represent the actual work a resource will do, and they don’t have an additional subtasks underneath them.
Step 3: Enter Task durations or work estimates
Work is the amount of effort or person hours needed to complete the task. Duration is the amount of actual time that will pass before the task is completed. If a task is completed by one person in 16 hours, assuming each day working hours is 8 hours; duration will be equal to 2 days. Units can be either in hours, days or weeks. When duration is entered for the task it is important that the duration is entered at the sub task level estimate accurately.
Step 4: Create dependencies between tasks
One of the most critical steps in scheduling is to create task dependencies, or links. This step makes the difference between a plan that can be used as an effective management tool and a plan that can be used a presentation tool.
A dependency occurs when start or finish of one task depends upon start or finish of another task. After the dependencies are set, you can easily identify the critical path and understand the driving factors of the project end date. You can also see the ripple effect in the project when changes are made to a particular task. The challenge planners have is to ensure that all tasks are in the dependency chain.
Step 5: Assign Resources
Resources are allocated based on the needs and priority of the tasks. There are three possible approaches
1. Use project to show responsibility for tasks: This approach takes the least effort to enter and maintain. However, it does not give you any real insight into the status of work during the course of the project.
2. Use project to forecast resource requirements: This approach requires additional effort to enter and maintain assignments, and also requires assigning the correct work and unit values up front in the planning process. It provides more accurate information upfront but does not provide information about the status of work during the project.
3. Use project to forecast resource requirements and track what work resources actually do on tasks: This approach allows managers to see how work on tasks is progressing during the course of the project.
How to Spot a Failing Project
With the high rate of failure in project management that 2 out of 5 projects fail and the larger the project, the more failure it experiences. There are some reasons what symptoms tell us project management is going wrong. While the commonly failing reason includes lack of management support and unclear objective, it suggests ten intangible warning signs to look out here:
1. Lack of interest. They have to make it sure if everybody really agreed to where they are heading for and check if they have shared same goals and objectives when conflict occurs. Positive environment helps project management to be successful.
2. Poor communication. If there is formal and informal lack of communication, it can be the warning sign.
3. Lack of velocity. Velocity is key concept in successful project management because it makes tracking progress easier along with imposing a feeling of success and team morale. Jim Johnson of Standish group says that one of the classical signs a project is in trouble is that things aren’t moving.
4. A “no-bad-news” environment. Everybody does not want to hear about bad news. However, if there forms the environment not to spread bad news, the bad news can be slow to reach people and result in fatal outcome to miss the opportunity of correcting that. The acceptance environment of bad news should be established by leaders and CIOs to prevent awful result later on.
5. Concrete signs. Some of the warning signs are visible and obvious. Good organization providing executive visibility has less tendency of pop up trouble in the last minute of the work.
6. A lot of overtime. Overwork is usually used by project manager because it is fast and easy way to fix project management to keep the schedule while no workers welcome it in reality. When team members’ health condition deteriorates, it can be another sign and result of overwork that the project is going bad.
7. Diversion of resources. It can be usually seen that the resource, commonly people, pull off from the project to work other things. Time and resources are limited for the project, so they should be controlled and managed wisely.
8. Ratios trouble. Compare the budgeted time, money and schedule with actually spent or implemented results. It easily let you know where you are and where you should be.
9. Milestones aren’t met. It is better to set the milestone weekly with small piece to get the feedback and concrete result which enables avoiding the risk in the future. The lines of code written are classic example to measure process.
10. Scope changes. For example, requirements can change and it itself is not bad. However, they have to be checked what requirements changes and why they changes to keep the project management in healthy way.
All of the 10 things mentioned above are just sign, and does not mean that project has failed or is about to fail. However, they can be good indicators that needs close attention from project managers and people in the position of responsibility to avoid failure of project management.
Cook, R. & Johnson, S. (2007). How to Spot a Failing Project. Retrieved from http://www.attask.com/images/library/CIO_Article.pdf
A reliable BI system increases the business intelligence - a PM story
This is an entry for documenting what I recommend to address a systematic problem in my internship organization. To avoid the concern about the disclosure of sensitive data and situation, the organization title refers to ABC institution in following description.
Background:
ABC institution is a business school who provides the international executive education and business consulting service.
Although ABC’s main product is imaginable product, I still can see a product as a set of activities including 4C (contact, consult, composing, until closing the deals after delivering the courses.).
As the challenges mentioned above, the report suggests tackling those problems by CRM system and knowledge management system. While the systems are the tool to accelerate the effects, they should be underpinned by following main concept.
1) A customer centricity and service to turn “push marketing” into “pull marketing”
The original way we are using right now is a “push marketing”, which means we push the information to our clients, hoping they accept our offers. The idea of the customer centricity is that we boost the sales by raising clients self awareness, providing a central dashboard for each client, showing the information about how competitive they are, in terms of the employees’ talent by converting the total amount of courses the clients (both corporate accounts and individual accounts) have taken compared to the benchmarks in the same industry they have taken. By doing so, the clients would check whether there is lack of some specific knowledge or whether they under the average within same industry, and checking their knowledge inventory. The comparison will raise clients’ awareness or stimulate their human resource planning in a long run. The dashboard will designed to send the core competency reports by a certain period to remind clients’ human resource stuff to increase their business and employees talent by purchasing the ABC institution’s programs or contact with our product managers. Therefore, we are turning “push marketing” into “pull marketing”.
2) A reliable BI system increases the business intelligence
Since the core competency of ABC institution is knowledge intensive, Knowledge management is the key to maintain its competitive advantages. We can use knowledge management to help ABC institution more effectively create, capture, synthesize, deploy, share, and reuse organizational knowledge by a set of activities aided by information technology infrastructures. However, the building of knowledge database is time consuming and could not take place in a single period time; it requires a continually inputs from all employees. Therefore, the report suggests that to design an encyclopedia, storing all information, including key program, new products, and advertising campaign details.
Further, this system can be connected with CRM system as well; for example, after the representative fulfill the questions, the report can be sent to customers by email, leaving a very clear message.
3) Automations to reduce the product leading time and unnecessary people error
The essential factor to implement the automations is to digitalize every single data. The best way to achieve this goal is to have the digital inputs in the very beginning. Although ABC institution has introduced the intranet, some of the information still needs to be keyin manually such as the enquiry from callings. To solve this situation and to connect with other suggestion mentioned above, we can initiative the digital inputs from the business leads, both the leads generated from online inquiries, offline seminars, and clients referrals.
4) Knowledge managementto reuse the developed knowledge and, to increase FDC’s business intelligence automatically
ABC institution is a place bound with lots of brilliant people, producing the knowledge and business solution all the day even the operation itself keeps producing business intelligence as well. However, those knowledge is scatted everywhere, moreover, no process to record those intangible assets automatically, in result of less utilization of ABC institution’s assets. To address this problem, the knowledge management is recommended to apply as the supply chain management for retailers. For example, first, to input the existing data such as the competitors portfolios, seminar performance documents in a systematic way, the KM system then automatically prioritizes solution documents based on "usefulness-frequency of use" in resolving specific problems; the higher priority ones rise to the top of the list. The automatically prioritization can apply to both customers service receiving the callings and the product managers developing the programs for companies. In the result of prioritization, the knowledge can be shared and improved by different people (a good example is Wikipedia and the economic emerging due to Wikipedia); further, the “most frequency questions”, “the most popular/ useful/ common business solutions” will be read, applied, updated as well so that FDC shaped the (the best practice would be Google’s searching ranking methodology that weights the ranking of most popular web pages based on users, surfers’ clicks, assuming that the web pages which earn the most clicks imply the most useful web pages for certain keywords.
In general, the one effective way to build what every reliable BI system needs- a single version of the truth; therefore, to create a data warehouse, a central repository that is fed by various systems of the company (mailing list, sales, alumni portfolios) and reflects a definitive picture of what is happening is the most essential element.
Modeling the New Procedures
This report is an initial study for internal communication improvement. Although the intention is original form couple divisions, it extends the scale that embrace the whole organization; further, the completed implementation can improve not only the internal communication but also increase the business intelligence. Moreover, by highly utilize the knowledge assets, reducing the service lead time and so on, ABC institution can build the foremost competitive advantages; for example, “providing solutions in 7 days”, “monitor your business intelligence in real time”.
1. Providing solutions in 7 days.
Since the problems in companies are inclusive in couple aspects such as “internationalization”, “marketing”, “finance” and so on. We can document the solutions that we already developed for reusing it on the similar case so that we can reduce the lead time of delivering products.
2. Monitoring your business intelligence in real time.
When our system is designed for customer-centric, every companies or individual can have an account which records what kind courses that have been taken, and how competitive you are in terms of knowledge capability and so on.
The member also can see other companies’ record as the benchmarks.
Those two functions would build the core competency as well.
Implementation
To implement this project, it requires a experienced IT vendor to support the equipment, developing, and maintenance. To choose the ideal vendor, I recommend either outsource to the original vendor who support ABC institution’s existing intranet system or host a competition, distribute part of this report to candidates as a guild line, asking them to propose a feasible solution and price.
Background:
ABC institution is a business school who provides the international executive education and business consulting service.
Although ABC’s main product is imaginable product, I still can see a product as a set of activities including 4C (contact, consult, composing, until closing the deals after delivering the courses.).
As the challenges mentioned above, the report suggests tackling those problems by CRM system and knowledge management system. While the systems are the tool to accelerate the effects, they should be underpinned by following main concept.
1) A customer centricity and service to turn “push marketing” into “pull marketing”
The original way we are using right now is a “push marketing”, which means we push the information to our clients, hoping they accept our offers. The idea of the customer centricity is that we boost the sales by raising clients self awareness, providing a central dashboard for each client, showing the information about how competitive they are, in terms of the employees’ talent by converting the total amount of courses the clients (both corporate accounts and individual accounts) have taken compared to the benchmarks in the same industry they have taken. By doing so, the clients would check whether there is lack of some specific knowledge or whether they under the average within same industry, and checking their knowledge inventory. The comparison will raise clients’ awareness or stimulate their human resource planning in a long run. The dashboard will designed to send the core competency reports by a certain period to remind clients’ human resource stuff to increase their business and employees talent by purchasing the ABC institution’s programs or contact with our product managers. Therefore, we are turning “push marketing” into “pull marketing”.
2) A reliable BI system increases the business intelligence
Since the core competency of ABC institution is knowledge intensive, Knowledge management is the key to maintain its competitive advantages. We can use knowledge management to help ABC institution more effectively create, capture, synthesize, deploy, share, and reuse organizational knowledge by a set of activities aided by information technology infrastructures. However, the building of knowledge database is time consuming and could not take place in a single period time; it requires a continually inputs from all employees. Therefore, the report suggests that to design an encyclopedia, storing all information, including key program, new products, and advertising campaign details.
Further, this system can be connected with CRM system as well; for example, after the representative fulfill the questions, the report can be sent to customers by email, leaving a very clear message.
3) Automations to reduce the product leading time and unnecessary people error
The essential factor to implement the automations is to digitalize every single data. The best way to achieve this goal is to have the digital inputs in the very beginning. Although ABC institution has introduced the intranet, some of the information still needs to be keyin manually such as the enquiry from callings. To solve this situation and to connect with other suggestion mentioned above, we can initiative the digital inputs from the business leads, both the leads generated from online inquiries, offline seminars, and clients referrals.
4) Knowledge managementto reuse the developed knowledge and, to increase FDC’s business intelligence automatically
ABC institution is a place bound with lots of brilliant people, producing the knowledge and business solution all the day even the operation itself keeps producing business intelligence as well. However, those knowledge is scatted everywhere, moreover, no process to record those intangible assets automatically, in result of less utilization of ABC institution’s assets. To address this problem, the knowledge management is recommended to apply as the supply chain management for retailers. For example, first, to input the existing data such as the competitors portfolios, seminar performance documents in a systematic way, the KM system then automatically prioritizes solution documents based on "usefulness-frequency of use" in resolving specific problems; the higher priority ones rise to the top of the list. The automatically prioritization can apply to both customers service receiving the callings and the product managers developing the programs for companies. In the result of prioritization, the knowledge can be shared and improved by different people (a good example is Wikipedia and the economic emerging due to Wikipedia); further, the “most frequency questions”, “the most popular/ useful/ common business solutions” will be read, applied, updated as well so that FDC shaped the (the best practice would be Google’s searching ranking methodology that weights the ranking of most popular web pages based on users, surfers’ clicks, assuming that the web pages which earn the most clicks imply the most useful web pages for certain keywords.
In general, the one effective way to build what every reliable BI system needs- a single version of the truth; therefore, to create a data warehouse, a central repository that is fed by various systems of the company (mailing list, sales, alumni portfolios) and reflects a definitive picture of what is happening is the most essential element.
Modeling the New Procedures
This report is an initial study for internal communication improvement. Although the intention is original form couple divisions, it extends the scale that embrace the whole organization; further, the completed implementation can improve not only the internal communication but also increase the business intelligence. Moreover, by highly utilize the knowledge assets, reducing the service lead time and so on, ABC institution can build the foremost competitive advantages; for example, “providing solutions in 7 days”, “monitor your business intelligence in real time”.
1. Providing solutions in 7 days.
Since the problems in companies are inclusive in couple aspects such as “internationalization”, “marketing”, “finance” and so on. We can document the solutions that we already developed for reusing it on the similar case so that we can reduce the lead time of delivering products.
2. Monitoring your business intelligence in real time.
When our system is designed for customer-centric, every companies or individual can have an account which records what kind courses that have been taken, and how competitive you are in terms of knowledge capability and so on.
The member also can see other companies’ record as the benchmarks.
Those two functions would build the core competency as well.
Implementation
To implement this project, it requires a experienced IT vendor to support the equipment, developing, and maintenance. To choose the ideal vendor, I recommend either outsource to the original vendor who support ABC institution’s existing intranet system or host a competition, distribute part of this report to candidates as a guild line, asking them to propose a feasible solution and price.
Sunday, November 2, 2008
IT project experience - establish CMS for exchange program
While working for the Japanese Consulate in Vancouver, I coordinated a project to establish a Contents Management System for an exchange program run by the Japanese government. The Japan Exchange and Teaching (JET) program was established some 20 years ago by the government, and it has been recognized as a very successful program in promoting cultural exchange between Japan and more than 40 countries in the world. The program invites foreign youth to Japanese municipalities to experience Japanese culture and to teach foreign languages at Japanese public schools every year. From Vancouver, about 100 Canadian university graduates are annually sent to Japan on the JET program. The program aims to promote the understanding of Japan at a grass-roots level in foreign countries.
In fact, among the past JET participants, there are a quite few who have become quite successful in the fields of business, education, and politics, in their home countries. However, the Japanese government has done a poor job of maintaining contact with these former participants. Recently, losing contact with past JET participants has been recognized as a great loss for the program. Under such circumstances, the government decided to establish a CMS as a tool to keep a bond with the past, present, and future JET participants around the world. The CMS will contain all the contact information of the JET participants and connect the web pages of the JET alumni association as well as those of the Japanese municipalities and government. After almost two years of debate on the project in Tokyo, the budget was finally approved for establishing a CMS. Since the IT vendor, which was a company owned by one of the of JET alumni, is located in Vancouver, I happened to be assigned to coordinate this project.
Although the project looked fairly simple at the beginning, the completion was delayed and was more than a half year behind schedule. The main reasons for the delay were the legal aspects associated with the project and the difficulty of managing the IT vendor relationship. On the legal side, we had to consider a number of issues, such as the location of the server and protection of personal information. We had to understand when we set up a server for the CMS in Vancouver, what kind of legal impact it would have on the users who are in different countries. We had to also be concerned with how much privacy protection was to be given to personal information in the CMS. Since neither the IT vendor nor I had any experience in similar projects, we almost had to learn everything from scratch. The IT vendor and I consulted lawyers, and it took more than three months before we understood the legal environment and agreed on the basic framework of the project.
Managing the IT vendor was also extremely difficult in this project. This small IT company, run by a JET alumnus, had been involved in this project from two years ago. This company spent a lot of time and resources debating with the Japanese government even before I got involved in this project. When I began working with this company, their motivation level was very low. Further, due to budget constraints, the government said from the beginning that they could not pay competitive fees to this company. Thus, this project work always remained low in the IT vendor’s priority list. This made it so difficult for me to deliver the result by the scheduled deadline. I was always going back and forth between the government office in Tokyo and the IT vendor to make progress on the project. Finally, after two years, the CMS was released with an eight month delay in the schedule.
I found this project a very tiring experience since I had no choice but to work with an unenthusiastic vendor and a limited budget. I always had to worry about the payment schedule since the budget for each quarter could not be carried over to the next quarter under the special budget allocated for this project, but I never knew when the vendor would be able to show us the scheduled partial deliverables in each quarter. I felt many times that there was no way to complete the project. After everything was over, looking back, I wonder if I could have gained more management buy-in on this project. This seemed impossible at that time, since my direct supervisor was extremely busy with something else and did not have interest in this project. As there was not any strong support from the Tokyo office, I felt this project was imposed on me only because the vendor was in Vancouver. After all, not only myself but the people who worked for me and the IT vendor had a very hard time throughout the duration of the project. If I had a similar opportunity in the future, I hope I could have more buy-in from top management and effective support in order to better manage the project.
In fact, among the past JET participants, there are a quite few who have become quite successful in the fields of business, education, and politics, in their home countries. However, the Japanese government has done a poor job of maintaining contact with these former participants. Recently, losing contact with past JET participants has been recognized as a great loss for the program. Under such circumstances, the government decided to establish a CMS as a tool to keep a bond with the past, present, and future JET participants around the world. The CMS will contain all the contact information of the JET participants and connect the web pages of the JET alumni association as well as those of the Japanese municipalities and government. After almost two years of debate on the project in Tokyo, the budget was finally approved for establishing a CMS. Since the IT vendor, which was a company owned by one of the of JET alumni, is located in Vancouver, I happened to be assigned to coordinate this project.
Although the project looked fairly simple at the beginning, the completion was delayed and was more than a half year behind schedule. The main reasons for the delay were the legal aspects associated with the project and the difficulty of managing the IT vendor relationship. On the legal side, we had to consider a number of issues, such as the location of the server and protection of personal information. We had to understand when we set up a server for the CMS in Vancouver, what kind of legal impact it would have on the users who are in different countries. We had to also be concerned with how much privacy protection was to be given to personal information in the CMS. Since neither the IT vendor nor I had any experience in similar projects, we almost had to learn everything from scratch. The IT vendor and I consulted lawyers, and it took more than three months before we understood the legal environment and agreed on the basic framework of the project.
Managing the IT vendor was also extremely difficult in this project. This small IT company, run by a JET alumnus, had been involved in this project from two years ago. This company spent a lot of time and resources debating with the Japanese government even before I got involved in this project. When I began working with this company, their motivation level was very low. Further, due to budget constraints, the government said from the beginning that they could not pay competitive fees to this company. Thus, this project work always remained low in the IT vendor’s priority list. This made it so difficult for me to deliver the result by the scheduled deadline. I was always going back and forth between the government office in Tokyo and the IT vendor to make progress on the project. Finally, after two years, the CMS was released with an eight month delay in the schedule.
I found this project a very tiring experience since I had no choice but to work with an unenthusiastic vendor and a limited budget. I always had to worry about the payment schedule since the budget for each quarter could not be carried over to the next quarter under the special budget allocated for this project, but I never knew when the vendor would be able to show us the scheduled partial deliverables in each quarter. I felt many times that there was no way to complete the project. After everything was over, looking back, I wonder if I could have gained more management buy-in on this project. This seemed impossible at that time, since my direct supervisor was extremely busy with something else and did not have interest in this project. As there was not any strong support from the Tokyo office, I felt this project was imposed on me only because the vendor was in Vancouver. After all, not only myself but the people who worked for me and the IT vendor had a very hard time throughout the duration of the project. If I had a similar opportunity in the future, I hope I could have more buy-in from top management and effective support in order to better manage the project.
Project Failure Prevention: 10 Principles for Project Control
Project Failure Prevention: 10 Principles for Project Control
Tom Gilb in his article describes that a lot of projects fail, no matter if they are engineering projects or software engineering projects. He describes 10 principles for project control that if used wisely, can save a lot of projects. Here is a summary of those principles:
P1 – Critical Measures
This principle states that the critical product objectives need to be stated in a way that they can be measured. The project needs to have a well-written set of top-level requirements which include the critical product characteristics with a set of measurements for those characteristics. For example, in the objectives one can say that the firm needs state-of-the-art security, but it is much better to state that the firm needs 99.89% reliability.
P2 – Pay for Results
This principle states that the project team has to be rewarded to the degree the project achieves the critical product objectives (described in P1). The author states that project teams when do not deliver specifications or when schedule is not met, usually management gives them more money or more time to finish the requirements. Team are being rewarded with more money or more time when results are not good. The author suggest the contrary to “punish” them when requirements are not met.
P3 – Architecture for Quality
This principle states that there is a need for a top-level architecture process that will be the guiding parameter for the whole project. That top-level architecture process has to specify design strategies to enable the critical product objectives. This principle is concerned in building good foundations for the project.
P4 – Clear Specifications
This principle states that the specifications have to be super clear. The specifications have to be clear enough that they can be tested, they have to be unambiguous to the intended readership and that there should not be any unintentional design requirements. The specifications have to be easy to read for any kind or reader.
P5 – Design must meet business needs
This principle states that the specifications have to be carefully reviewed to see if the designs meet the business needs. Again, designs should be well written and easy to read. After reviewing the design, an analysis has to be made to see if the business requirements are going to be fulfilled with the design. Detail is needed so there is no confusion in latter parts of the project. The design has to have resource estimates.
P6 – Validate Strategies Early
This principle states that high-risk strategies have to be validated in early stages of the project. Those high-risk strategies are the ones that will impact the levels of performance and cost. Also those strategies are the ones that can ruin or make a project fail. To validate strategies, project teams can build pilots, trails, experiments, prototypes, etc. This principle is the one related to Risk Management.
P7 – Resources for Designs
Resources like money, human effort and calendar time have to be allocated carefully to meet the required design. Each design and each project have specific characteristics, and good resources are not necessary good in some situations, so the resources should be allocated according to the design, they have to be allocated to enable the design.
P8 – Early Value Delivery
This principle states that the stakeholder value has to be delivered as early as possible. The author suggests that projects have to be planned in an evolutionary way. The most basic requirements or objectives should be done first, and around those, the new phases should be built.
P9 – Avoid Unnecessary Design Constraints
This principle states that requirements and specifications should not include unnecessary constraints that could impact performance and value. This principle suggests that the designs and solutions should impact business needs instead of being done to satisfy technical designs. The author suggests that projects should use the technology to satisfy requirements, not the other way around.
P10 – Value before Bureaucracy
This principle states that “the project should be free to give priority to value delivery and not to be constrained by well-intended processes and standards”. (Gilb, 2005). Bureaucracy can impact project performance if it delays decision making. Project management should have the power to make fast high impact decisions.
Reference: Tom Gilb. Copyright 2005-2006 by Tom Gilb. Published and used by Methods & Tools with permission. www.methodsandtools.com
Tom Gilb in his article describes that a lot of projects fail, no matter if they are engineering projects or software engineering projects. He describes 10 principles for project control that if used wisely, can save a lot of projects. Here is a summary of those principles:
P1 – Critical Measures
This principle states that the critical product objectives need to be stated in a way that they can be measured. The project needs to have a well-written set of top-level requirements which include the critical product characteristics with a set of measurements for those characteristics. For example, in the objectives one can say that the firm needs state-of-the-art security, but it is much better to state that the firm needs 99.89% reliability.
P2 – Pay for Results
This principle states that the project team has to be rewarded to the degree the project achieves the critical product objectives (described in P1). The author states that project teams when do not deliver specifications or when schedule is not met, usually management gives them more money or more time to finish the requirements. Team are being rewarded with more money or more time when results are not good. The author suggest the contrary to “punish” them when requirements are not met.
P3 – Architecture for Quality
This principle states that there is a need for a top-level architecture process that will be the guiding parameter for the whole project. That top-level architecture process has to specify design strategies to enable the critical product objectives. This principle is concerned in building good foundations for the project.
P4 – Clear Specifications
This principle states that the specifications have to be super clear. The specifications have to be clear enough that they can be tested, they have to be unambiguous to the intended readership and that there should not be any unintentional design requirements. The specifications have to be easy to read for any kind or reader.
P5 – Design must meet business needs
This principle states that the specifications have to be carefully reviewed to see if the designs meet the business needs. Again, designs should be well written and easy to read. After reviewing the design, an analysis has to be made to see if the business requirements are going to be fulfilled with the design. Detail is needed so there is no confusion in latter parts of the project. The design has to have resource estimates.
P6 – Validate Strategies Early
This principle states that high-risk strategies have to be validated in early stages of the project. Those high-risk strategies are the ones that will impact the levels of performance and cost. Also those strategies are the ones that can ruin or make a project fail. To validate strategies, project teams can build pilots, trails, experiments, prototypes, etc. This principle is the one related to Risk Management.
P7 – Resources for Designs
Resources like money, human effort and calendar time have to be allocated carefully to meet the required design. Each design and each project have specific characteristics, and good resources are not necessary good in some situations, so the resources should be allocated according to the design, they have to be allocated to enable the design.
P8 – Early Value Delivery
This principle states that the stakeholder value has to be delivered as early as possible. The author suggests that projects have to be planned in an evolutionary way. The most basic requirements or objectives should be done first, and around those, the new phases should be built.
P9 – Avoid Unnecessary Design Constraints
This principle states that requirements and specifications should not include unnecessary constraints that could impact performance and value. This principle suggests that the designs and solutions should impact business needs instead of being done to satisfy technical designs. The author suggests that projects should use the technology to satisfy requirements, not the other way around.
P10 – Value before Bureaucracy
This principle states that “the project should be free to give priority to value delivery and not to be constrained by well-intended processes and standards”. (Gilb, 2005). Bureaucracy can impact project performance if it delays decision making. Project management should have the power to make fast high impact decisions.
Reference: Tom Gilb. Copyright 2005-2006 by Tom Gilb. Published and used by Methods & Tools with permission. www.methodsandtools.com
The New CRM System - Company PM Story
I was recently involved in the project of upgrading the CRM system of my company to a more “advanced, interactive, powerful, and user-friendly” one. The new system was launched recently, but already several months overdue and also way over budget. I think it is to a large extent a failed project even though we do have a new system running now.
As a team member, I have observed the following mistakes:
1. The CFO of the company was assigned to be the Project Manager who has no previous project management experience, no IT technical background, and no direct involvement in the sales and marketing group who will be the users of the CRM system.
2. The CFO then oversold to the CEO (who also has no IT background and will not be an active user of the system) the system he was going to purchase and implement. The CEO was mainly interested in the reporting functions of the new system and had high expectations of the effectiveness of the new system, therefore giving his full support to the project. The CFO, in order to gain the CEO’s support, painted a “wonderful picture” of the new system to the CEO, not realizing that many of the functionalities he described were not going to be included in the new system, at least not if a significant amount of extra cost was not incurred to have those functionalities added. Obviously the CFO got the “picture” from the sales people of the company that was trying to sell us the system.
3. The company that was selling the new system then assigned their consultants to start designing and customizing the system based on our needs, and afterwards also migrated the data from our old system to the new system. The consultants were working with the CFO and our IT Manager on the designing and customization phases, but no comprehensive consultations with the sales and marketing group or the CEO. Therefore user needs, expectations, and requirements were not fully understood by the consultants.
4. After a few months of work, the new system was then launched on a trail basis to a limited group of users for initial evaluation. It was at this moment that serious deficiencies were discovered that major functionalities that were originally expected were not included. There was an outcry from the trial users and the CEO demanded those functionalities to be included, only being told that a significant amount of extra cost had to be incurred for that. The CEO approved it and the project continued.
5. The re-launch of the new system was then delayed again and again and new extra costs were added periodically as more and more deficiencies were discovered and had to be resolved. Finally under the pressure of the CEO, the system was re-launched, but as described by the CFO: this was only Phase 1 and more work had to be done.
6. The system is now being used in the company, even though complaints are heard regularly about the user-unfriendliness, the lack of expected functionalities, the deficiencies, etc. It was also mentioned many times that the new system was actually worse than the old system. And as mentioned earlier, the project was far from complete and many more months and much more money have still to be put on this project to try to achieve what the system was supposed to do, if achievable at all.
It is very clear from this case that without using and implementing project management best practices, a project is almost doomed to fail.
As a team member, I have observed the following mistakes:
1. The CFO of the company was assigned to be the Project Manager who has no previous project management experience, no IT technical background, and no direct involvement in the sales and marketing group who will be the users of the CRM system.
2. The CFO then oversold to the CEO (who also has no IT background and will not be an active user of the system) the system he was going to purchase and implement. The CEO was mainly interested in the reporting functions of the new system and had high expectations of the effectiveness of the new system, therefore giving his full support to the project. The CFO, in order to gain the CEO’s support, painted a “wonderful picture” of the new system to the CEO, not realizing that many of the functionalities he described were not going to be included in the new system, at least not if a significant amount of extra cost was not incurred to have those functionalities added. Obviously the CFO got the “picture” from the sales people of the company that was trying to sell us the system.
3. The company that was selling the new system then assigned their consultants to start designing and customizing the system based on our needs, and afterwards also migrated the data from our old system to the new system. The consultants were working with the CFO and our IT Manager on the designing and customization phases, but no comprehensive consultations with the sales and marketing group or the CEO. Therefore user needs, expectations, and requirements were not fully understood by the consultants.
4. After a few months of work, the new system was then launched on a trail basis to a limited group of users for initial evaluation. It was at this moment that serious deficiencies were discovered that major functionalities that were originally expected were not included. There was an outcry from the trial users and the CEO demanded those functionalities to be included, only being told that a significant amount of extra cost had to be incurred for that. The CEO approved it and the project continued.
5. The re-launch of the new system was then delayed again and again and new extra costs were added periodically as more and more deficiencies were discovered and had to be resolved. Finally under the pressure of the CEO, the system was re-launched, but as described by the CFO: this was only Phase 1 and more work had to be done.
6. The system is now being used in the company, even though complaints are heard regularly about the user-unfriendliness, the lack of expected functionalities, the deficiencies, etc. It was also mentioned many times that the new system was actually worse than the old system. And as mentioned earlier, the project was far from complete and many more months and much more money have still to be put on this project to try to achieve what the system was supposed to do, if achievable at all.
It is very clear from this case that without using and implementing project management best practices, a project is almost doomed to fail.
Motivation: How to increase project team performance
There are a lot of different aspects in project management we have already discussed in our course. The team motivation is, however, another important issue which I would like to consider in some more details. Unlike many other issues of project management such as project life cycle, planning, scheduling and etc., the motivation is completely intangible. There is no easy way to formalize or even describe it. Nevertheless, the motivation is so important that I decided to discuss briefly some contemporary approaches which might help you in your career of project manager. I start with short introduction to motivation theories, describe some common motivation mistakes and wrap up with some important team building issues.
There are the following motivational theories for project team management: McGregor’s Theory X and Y, Herzberg’s KITA, McClelland’s Achievement, Affiliation and Power motivation as well as MBTI personal style.
McGregor’s Theory X and Y basically assumes that two types of project team members exist, X and Y. X team members are those who are low motivated and require constant attention form project manager. On the opposite, Y team members are highly motivated individuals who do not need a lot of supervision to get their work done well and on time. The project manager motivation approach depends on which team members’ type, X or Y, he works with. The disadvantage of this theory is that typical project team environment is a mix of type X and type Y individuals which require a project manager to accommodate balanced leadership style to effectively motivate both types in the same environment.
Herzberg’s KITA (Kick In The Pants) motivation theory is based on the idea that both positive and negative motivators exists. The project manager has to use “carrots” (positive KITA) and “sticks” (negative KITA) to motivate the project task completion. Advantage of this approach is that the project manager is able to create the atmosphere of goal achievement which drives the project success. Disadvantage of such motivation is that it creates “I am ok, you are not ok” relationships between PM and team members. The competition and lack of trust, resulted in that, may destroy the cooperative atmosphere in the project team.
McClelland’s Achievement, Affiliation and Power motivation framework is focused on individuals who are oriented on personal achievement, driven by comfortable work with others (affiliation) or motivated by power. Each type of these individuals has specific potential advantages and disadvantages for team dynamics. The theory explains how the project managers may effectively deal with all of these types.
MBTI personal style or the Meyrs-Briggs Type Indicator provides the ability to identify the personal motivation styles of project team members. Knowing these styles, the project manager could apply personalized approach and task direction for each member of his team. The sophisticated personalized motivation is the main advantage of this approach. The disadvantage is that it takes additional efforts to make necessary individual assessments.
You may find the more detailed description of all motivational theories described above in the Internet.
Typical motivational mistakes which I would like to mention are the following:
o Whatever motivates me – will motivate others. The result of this mistake is disappointment in team members who behave differently;
o People are motivated primary by money. PM are typically constrained in giving monetary rewards so they have to look for non-monetary motivation tactics;
o Team members love to receive formal awards. Other project team members might react negatively on such type of individualized recognition. Be very careful with that;
o The best project leader is the strong cheer leader. Though generally effective, this approach could not be applicable in problematic situations and might cause the opposite results;
o I will treat everyone the same. All individuals are different in terms of culture, experience, education etc. Individualized motivation is more effective in such environment.
Important team building issues in project management to mention here are the high-performing teamwork and the building team culture. High-performing teamwork is based on the high involvement of the team members on the all stages of project life cycle such as planning of tasks, time estimation, risk reviews etc. The involvement of the team provides the project manager valuable insights about the complexity and arrangements of the project efforts. Team members would feel much more ownership and acceptance of the team efforts as well.
Building high performing team culture is another important issue to focus on. The following steps should be accomplished to create good project team culture:
o Team processes – defining common team processes with well known performance expectations and standards;
o Celebrate team successes;
o Foster trust, teamwork and open communication;
o Recognize team members’ strengths – the project tasks needs to be assigned according to individual strengths, knowledge and motivation;
o Promote Project Success – continually identify the successes the team has accomplished (no matter what the size of these successes is).
To sum up, the PM must recognize the importance of individuality for effective project team motivation. Based on my experience this is the key to effective and successful project management.
Reference:
Peterson, Tonya M. Project Management Journal, Dec2007, Vol. 38 Issue 4, p60-69
http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=29413504&site=ehost-live
There are the following motivational theories for project team management: McGregor’s Theory X and Y, Herzberg’s KITA, McClelland’s Achievement, Affiliation and Power motivation as well as MBTI personal style.
McGregor’s Theory X and Y basically assumes that two types of project team members exist, X and Y. X team members are those who are low motivated and require constant attention form project manager. On the opposite, Y team members are highly motivated individuals who do not need a lot of supervision to get their work done well and on time. The project manager motivation approach depends on which team members’ type, X or Y, he works with. The disadvantage of this theory is that typical project team environment is a mix of type X and type Y individuals which require a project manager to accommodate balanced leadership style to effectively motivate both types in the same environment.
Herzberg’s KITA (Kick In The Pants) motivation theory is based on the idea that both positive and negative motivators exists. The project manager has to use “carrots” (positive KITA) and “sticks” (negative KITA) to motivate the project task completion. Advantage of this approach is that the project manager is able to create the atmosphere of goal achievement which drives the project success. Disadvantage of such motivation is that it creates “I am ok, you are not ok” relationships between PM and team members. The competition and lack of trust, resulted in that, may destroy the cooperative atmosphere in the project team.
McClelland’s Achievement, Affiliation and Power motivation framework is focused on individuals who are oriented on personal achievement, driven by comfortable work with others (affiliation) or motivated by power. Each type of these individuals has specific potential advantages and disadvantages for team dynamics. The theory explains how the project managers may effectively deal with all of these types.
MBTI personal style or the Meyrs-Briggs Type Indicator provides the ability to identify the personal motivation styles of project team members. Knowing these styles, the project manager could apply personalized approach and task direction for each member of his team. The sophisticated personalized motivation is the main advantage of this approach. The disadvantage is that it takes additional efforts to make necessary individual assessments.
You may find the more detailed description of all motivational theories described above in the Internet.
Typical motivational mistakes which I would like to mention are the following:
o Whatever motivates me – will motivate others. The result of this mistake is disappointment in team members who behave differently;
o People are motivated primary by money. PM are typically constrained in giving monetary rewards so they have to look for non-monetary motivation tactics;
o Team members love to receive formal awards. Other project team members might react negatively on such type of individualized recognition. Be very careful with that;
o The best project leader is the strong cheer leader. Though generally effective, this approach could not be applicable in problematic situations and might cause the opposite results;
o I will treat everyone the same. All individuals are different in terms of culture, experience, education etc. Individualized motivation is more effective in such environment.
Important team building issues in project management to mention here are the high-performing teamwork and the building team culture. High-performing teamwork is based on the high involvement of the team members on the all stages of project life cycle such as planning of tasks, time estimation, risk reviews etc. The involvement of the team provides the project manager valuable insights about the complexity and arrangements of the project efforts. Team members would feel much more ownership and acceptance of the team efforts as well.
Building high performing team culture is another important issue to focus on. The following steps should be accomplished to create good project team culture:
o Team processes – defining common team processes with well known performance expectations and standards;
o Celebrate team successes;
o Foster trust, teamwork and open communication;
o Recognize team members’ strengths – the project tasks needs to be assigned according to individual strengths, knowledge and motivation;
o Promote Project Success – continually identify the successes the team has accomplished (no matter what the size of these successes is).
To sum up, the PM must recognize the importance of individuality for effective project team motivation. Based on my experience this is the key to effective and successful project management.
Reference:
Peterson, Tonya M. Project Management Journal, Dec2007, Vol. 38 Issue 4, p60-69
http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=29413504&site=ehost-live
Saturday, November 1, 2008
Lessons from Relaunching an Online Community
Background
In July 2007 I undertook a project to relaunch a web site for an online technical community. The 30,000+ member community consisted of application developers, report designers, dashboard designers, and IT administrators. There were three full-time employees (manager, colleague, and me) on the team, plus one somewhat technical contractor. The contractor was hired originally to help with some site design and maintenance, and given the shortage of available developers, I brought him on the project, even though I had my reservations about his technical abilities. As project manager, I had two main goals: 1) perform a technical migration of the underlying platform, and 2) redesign the look, feel, and navigation of the site.
The Project
I plunged head on into the project, developing and ranking business, user, and technical requirements, identifying stakeholders, developing project plans, and creating page layout designs and navigation flows. The original goal was to relaunch the community just before the user conference in early October, which gave me 3 months to pull this off. I was excited about making my vision of the community happen even though I had never managed a technical project before. After identifying all the requirements and getting sign-off from the key stakeholders, I worked with our contractor to identify all the customized code modules and then asked him to determine how to implement the same functionality on the latest platform. The customizations proved difficult and time-consuming to resolve and put the project 4 weeks over schedule. I was not going to make the early October launch so I revised the schedule again to target a late November launch, although I did not actively advertise this.
We had set up a development server with the latest software and had started to build out the pages by early September. Over the next month we tackled one technical issue after another but the issues never seemed to cease. I felt I was spinning many extra cycles putting out fires, making design changes, building and modifying pages at the expense of communicating with stakeholders, for example. In retrospect, by not committing to a launch date I allowed myself to be in constant develop and test mode. I learned that I should have prioritized better what I needed to accomplish and also held the contractor responsible for delivering on time. Better yet, we should have paid him a set amount for the project, contingent on delivering as agreed upon. Upon further reflection, I also made the mistake of looking to him to manage the project because I felt I was in over my head and not willing to take full ownership and control over the project.
By late November, I wanted to launch over the weekend. I had a go-no-go meeting with my Manager beforehand, but failed to impress him with my launch plan. It was apparent that there were too many gaps that could have put the community at risk. With a bruised ego, I reset the launch date to the weekend of December 8 and 9. By now I HAD to launch because we were way over schedule. During this time, I was contacted by our web marketing team. Based on an initial discussion, I made the mistaken assumption that they were not interested in my project but they came in at the last moment to request that all the designs follow the corporate standard. In a meeting with the team, I lost my temper as I was told by one member that he was going to recommend that the launch should be delayed AGAIN because the look and feel did not conform to standards. In the end, I pushed through this obstacle and was able to implement all the changes they requested but this was a stark reminder not only to err on the side of over communicating with all stakeholders but also to defend your project. Coming up to the launch weekend, we worked relentlessly to meet all the requirements but I felt I could have “worked the plan” better by being more stringent on the milestones. In the end, we worked all weekend and well into the night and delivered the new site, but had to sacrifice testing time. We did some testing right after we went live and everything seemed to be OK so by midnight Monday morning, we all went home. By the time I woke up the next morning, my inbox was overflowing with email about technical difficulties that employees were having with the site. While the launch was received well overall, we spent the next several weeks over the holidays fixing bugs and other issues.
Key Lessons
My key lessons were to do my homework before making time estimates, “plan the work and work the plan”, commit firmly to an end date, break the project into phases (that is a technical migration phase followed by a redesign phase), allocate generous testing time, hire the right people to be on the project, involve the stakeholder early and often, plan the resources required, and develop a more comprehensive project plan (scope, WBS, etc.) by closely following sound project management principles instead of just doing what I thought was logical.
In July 2007 I undertook a project to relaunch a web site for an online technical community. The 30,000+ member community consisted of application developers, report designers, dashboard designers, and IT administrators. There were three full-time employees (manager, colleague, and me) on the team, plus one somewhat technical contractor. The contractor was hired originally to help with some site design and maintenance, and given the shortage of available developers, I brought him on the project, even though I had my reservations about his technical abilities. As project manager, I had two main goals: 1) perform a technical migration of the underlying platform, and 2) redesign the look, feel, and navigation of the site.
The Project
I plunged head on into the project, developing and ranking business, user, and technical requirements, identifying stakeholders, developing project plans, and creating page layout designs and navigation flows. The original goal was to relaunch the community just before the user conference in early October, which gave me 3 months to pull this off. I was excited about making my vision of the community happen even though I had never managed a technical project before. After identifying all the requirements and getting sign-off from the key stakeholders, I worked with our contractor to identify all the customized code modules and then asked him to determine how to implement the same functionality on the latest platform. The customizations proved difficult and time-consuming to resolve and put the project 4 weeks over schedule. I was not going to make the early October launch so I revised the schedule again to target a late November launch, although I did not actively advertise this.
We had set up a development server with the latest software and had started to build out the pages by early September. Over the next month we tackled one technical issue after another but the issues never seemed to cease. I felt I was spinning many extra cycles putting out fires, making design changes, building and modifying pages at the expense of communicating with stakeholders, for example. In retrospect, by not committing to a launch date I allowed myself to be in constant develop and test mode. I learned that I should have prioritized better what I needed to accomplish and also held the contractor responsible for delivering on time. Better yet, we should have paid him a set amount for the project, contingent on delivering as agreed upon. Upon further reflection, I also made the mistake of looking to him to manage the project because I felt I was in over my head and not willing to take full ownership and control over the project.
By late November, I wanted to launch over the weekend. I had a go-no-go meeting with my Manager beforehand, but failed to impress him with my launch plan. It was apparent that there were too many gaps that could have put the community at risk. With a bruised ego, I reset the launch date to the weekend of December 8 and 9. By now I HAD to launch because we were way over schedule. During this time, I was contacted by our web marketing team. Based on an initial discussion, I made the mistaken assumption that they were not interested in my project but they came in at the last moment to request that all the designs follow the corporate standard. In a meeting with the team, I lost my temper as I was told by one member that he was going to recommend that the launch should be delayed AGAIN because the look and feel did not conform to standards. In the end, I pushed through this obstacle and was able to implement all the changes they requested but this was a stark reminder not only to err on the side of over communicating with all stakeholders but also to defend your project. Coming up to the launch weekend, we worked relentlessly to meet all the requirements but I felt I could have “worked the plan” better by being more stringent on the milestones. In the end, we worked all weekend and well into the night and delivered the new site, but had to sacrifice testing time. We did some testing right after we went live and everything seemed to be OK so by midnight Monday morning, we all went home. By the time I woke up the next morning, my inbox was overflowing with email about technical difficulties that employees were having with the site. While the launch was received well overall, we spent the next several weeks over the holidays fixing bugs and other issues.
Key Lessons
My key lessons were to do my homework before making time estimates, “plan the work and work the plan”, commit firmly to an end date, break the project into phases (that is a technical migration phase followed by a redesign phase), allocate generous testing time, hire the right people to be on the project, involve the stakeholder early and often, plan the resources required, and develop a more comprehensive project plan (scope, WBS, etc.) by closely following sound project management principles instead of just doing what I thought was logical.
Thursday, October 30, 2008
Review of a Project Management Tool - Change Management
After reading some blogs about Project Management and some reviews of Project Management books, I realized that a common topic was Leadership & Change Management.
Researching in those topics I found a Harvard Business Review article about change management that talks about the common mistakes that companies make in projects.
Here is a summary of those Common Mistakes:
The first common mistake is to not establish a sense of urgency. A lot of times management do not understand how change initiatives or new projects can drive employees out of their comfort zones. They just want to start the new project without considering the effects on the employees. If people are not motivated, the change initiative will go nowhere. Management has to establish a sense of urgency to start and to get good results out of a project. One way can be to present unpleasant facts, like competition gaining advantage over the market. Management has “to make the status quo seem more dangerous than launching into the unknown” (Kotter, 1995).
The second common mistake is not forming a good and powerful team to lead the change effort. First of all, if management is not fully compromised to the project, the change initiative will fail. Management has to be an active supporter and employees need to know it.
A third big mistake is not creating a vision about the new project or change initiative. The leaders of the change initiative have to create a good vision of the project that can be communicated throughout the whole company. That again can be a big problem, if there is a vision, and the employees that will be affected by the change do not know it, and do not know the importance of it, the project will be hard to implement. And most importantly “communication comes in both words and deeds, and the latter are often the most powerful form” (Kotter, 1995
Another mistake is not removing obstacles to achieve the new vision. Management has to think about the obstacles that are going to appear in the process of trying to achieve the new vision. They have to think carefully about all the aspects that can arise, and they have to put themselves in the employee’s shoes to find out the probable problems.
Another big error is not planning for and creating short-term wins. Short term wins foster the motivation of employees. Management has to find out ways to make employees feel that the project is advancing and that results are being achieved.
The last big mistake is not to anchorage changes into corporate culture. “In the final analysis, change sticks when it becomes “the way we do things around here”” (Kotter, 1995).
Reference
Kotter, John. Leading Change. Why Transformation Efforts Fail. (1995) Harvard
Business Review OnPoint, 1-10.
Researching in those topics I found a Harvard Business Review article about change management that talks about the common mistakes that companies make in projects.
Here is a summary of those Common Mistakes:
The first common mistake is to not establish a sense of urgency. A lot of times management do not understand how change initiatives or new projects can drive employees out of their comfort zones. They just want to start the new project without considering the effects on the employees. If people are not motivated, the change initiative will go nowhere. Management has to establish a sense of urgency to start and to get good results out of a project. One way can be to present unpleasant facts, like competition gaining advantage over the market. Management has “to make the status quo seem more dangerous than launching into the unknown” (Kotter, 1995).
The second common mistake is not forming a good and powerful team to lead the change effort. First of all, if management is not fully compromised to the project, the change initiative will fail. Management has to be an active supporter and employees need to know it.
A third big mistake is not creating a vision about the new project or change initiative. The leaders of the change initiative have to create a good vision of the project that can be communicated throughout the whole company. That again can be a big problem, if there is a vision, and the employees that will be affected by the change do not know it, and do not know the importance of it, the project will be hard to implement. And most importantly “communication comes in both words and deeds, and the latter are often the most powerful form” (Kotter, 1995
Another mistake is not removing obstacles to achieve the new vision. Management has to think about the obstacles that are going to appear in the process of trying to achieve the new vision. They have to think carefully about all the aspects that can arise, and they have to put themselves in the employee’s shoes to find out the probable problems.
Another big error is not planning for and creating short-term wins. Short term wins foster the motivation of employees. Management has to find out ways to make employees feel that the project is advancing and that results are being achieved.
The last big mistake is not to anchorage changes into corporate culture. “In the final analysis, change sticks when it becomes “the way we do things around here”” (Kotter, 1995).
Reference
Kotter, John. Leading Change. Why Transformation Efforts Fail. (1995) Harvard
Business Review OnPoint, 1-10.
Wednesday, October 29, 2008
Project Failure - Migration of T-Star
Project Background
T-Star was a back-office software system for Asset Management Companies (AMC) operating in Japan. Around 80% of AMC in Japan subscribed to T-Star for their daily operations. This project was an application migration project and was outsourced to an IT services provider in India. The estimated project cost for T-Star’s owner was 14 million USD.
Project Scope
This system was to be re-engineered on Java technologies. It was developed using COBOL and had 1.5 millions lines of code. This project was divided into 4 phases (System Analysis, Design, Development and Testing). The total duration of the project was around two years. The team size remained around 35-45 persons including three project managers.
End Result
The project ran for twelve months and was scarped after the end of the analysis phase. All project managers employed by the IT vendor resigned. The vendor also lost market reputation. This resulted into an adverse impact on its Japanese projects.
Key Mistakes (From Vendor Side)
Project Approach
Feedbacks provided by customer on use cases and business requirements on many instances was informal, verbal or were on hard copies. This resulted in confusions and a lot of time was wasted in tracking and managing feedbacks. The methodology selected was object oriented and iterative in nature but it ended up in standard SDLC customized model.
Customer Management
An active customer engagement starting from Sr. management level up to team level was desired. Relationship should have been managed more effectively from onsite (Japan) with dedicated account manager/onsite coordinator from the start of the engagement.
Resource Management
Resources with required skill set were not found on time resulting in poor quality of work. Many crucial resources e.g. Test Lead, SQA expert etc. could not be inducted in time which affected customer’s confidence. Some key resources including project managers left the project midway.
Culture and Language
This project like any other Japanese projects needed managers with prior Japanese project experience. Communication was a big issue as all customer communication was in Japanese. Team members faced language barriers.
Lessons we can learn from this project failure
Before start of any project- deliverables, risks, format of delivery and assumptions need to be clearly defined & communicated to all stakeholders. Set reasonable customer expectations in terms of what would be delivered, how frequently and on what quality levels. Always report issues and problems to the customer, those faced by the team due to lack of clarity in requirements, frameworks or any customer specified items (this was most often ignored!). Further, closure of above issues should be tied up with project schedule and quality of deliverable. Always ensure that enough time is budgeted for internal as well as customer reviews. Take customer feedbacks on time or else inform the customer the impact on schedule & cost due to late feedbacks. Document each and every customer feedback and do not rely on verbal or informal feedback. Set up a dedicated project management office to monitor, track and resolve critical project issues.
T-Star was a back-office software system for Asset Management Companies (AMC) operating in Japan. Around 80% of AMC in Japan subscribed to T-Star for their daily operations. This project was an application migration project and was outsourced to an IT services provider in India. The estimated project cost for T-Star’s owner was 14 million USD.
Project Scope
This system was to be re-engineered on Java technologies. It was developed using COBOL and had 1.5 millions lines of code. This project was divided into 4 phases (System Analysis, Design, Development and Testing). The total duration of the project was around two years. The team size remained around 35-45 persons including three project managers.
End Result
The project ran for twelve months and was scarped after the end of the analysis phase. All project managers employed by the IT vendor resigned. The vendor also lost market reputation. This resulted into an adverse impact on its Japanese projects.
Key Mistakes (From Vendor Side)
Project Approach
Feedbacks provided by customer on use cases and business requirements on many instances was informal, verbal or were on hard copies. This resulted in confusions and a lot of time was wasted in tracking and managing feedbacks. The methodology selected was object oriented and iterative in nature but it ended up in standard SDLC customized model.
Customer Management
An active customer engagement starting from Sr. management level up to team level was desired. Relationship should have been managed more effectively from onsite (Japan) with dedicated account manager/onsite coordinator from the start of the engagement.
Resource Management
Resources with required skill set were not found on time resulting in poor quality of work. Many crucial resources e.g. Test Lead, SQA expert etc. could not be inducted in time which affected customer’s confidence. Some key resources including project managers left the project midway.
Culture and Language
This project like any other Japanese projects needed managers with prior Japanese project experience. Communication was a big issue as all customer communication was in Japanese. Team members faced language barriers.
Lessons we can learn from this project failure
Before start of any project- deliverables, risks, format of delivery and assumptions need to be clearly defined & communicated to all stakeholders. Set reasonable customer expectations in terms of what would be delivered, how frequently and on what quality levels. Always report issues and problems to the customer, those faced by the team due to lack of clarity in requirements, frameworks or any customer specified items (this was most often ignored!). Further, closure of above issues should be tied up with project schedule and quality of deliverable. Always ensure that enough time is budgeted for internal as well as customer reviews. Take customer feedbacks on time or else inform the customer the impact on schedule & cost due to late feedbacks. Document each and every customer feedback and do not rely on verbal or informal feedback. Set up a dedicated project management office to monitor, track and resolve critical project issues.
Tuesday, October 28, 2008
It may not be textbook, but it's working so far...
so, i've recently completed a project which has been working quite well for our company... i'm not sure it can be considered textbook management and implementation of a project, but it seems to be working so far... any advice on how i could have done things differently/better, or what i should be looking out for in the weeks to come would be appreciated... i call it "enhancing the export order management process at company xx"
************
As the Manager for Production Planning and Delivery Execution for a company involved in offshore export, I was recently assigned the task of improving the Export Order Management Process at my company. Like many other companies, our company has over the years narrowed our business focus to our core competencies, and as such, outsource our export logistics to a broker, who manages our export shipments. This means that activities such as booking vessel space for containers, negotiating freight rates and managing relationships with carriers are handled by the broker.
The main challenge with this seemingly straight-forward business process was that our company runs SAP, while our small broker outfit operates on a simple query database within which all key order information is stored. With our broker having better access to real time information, the order management process used to rely on manual query downloads into a spreadsheet generated by one of the broker’s employees throughout the week, from which our company’s export order management and delivery execution was carried out.
The biggest issue with executing on “snapshot” query downloads was that the moment the query was downloaded into a spreadsheet, the data was outdated. That is, because the order management was affected by many variables such as changes in the ship’s schedule, production upsets, and customer changes, there was a need for “real time” data for both our employees and the broker to work off of.
The project was simple in concept: map the current process, identify data inputs (both source and people), determine critical data and who should be inputting the data into a “real time” environment. The real time environ from our perspective needed to be SAP, as this was our single “truth”, and we needed the broker and all other relevant parties to work off of SAP.
When the preceding was completed, I worked closely with an IT Business Architect, who took my business needs, worked with the end users to design the solution, and then went to work with IT Technical for the technical programming.
After 4 weeks of designing and programming, we moved on to a week of testing to create all possible scenarios imaginable and the solution passed the test. Our company now has all key export order management and delivery execution data in SAP, and SAP can at the clock of a button generate real time reports for all key personnel involved in export order management.
************
As the Manager for Production Planning and Delivery Execution for a company involved in offshore export, I was recently assigned the task of improving the Export Order Management Process at my company. Like many other companies, our company has over the years narrowed our business focus to our core competencies, and as such, outsource our export logistics to a broker, who manages our export shipments. This means that activities such as booking vessel space for containers, negotiating freight rates and managing relationships with carriers are handled by the broker.
The main challenge with this seemingly straight-forward business process was that our company runs SAP, while our small broker outfit operates on a simple query database within which all key order information is stored. With our broker having better access to real time information, the order management process used to rely on manual query downloads into a spreadsheet generated by one of the broker’s employees throughout the week, from which our company’s export order management and delivery execution was carried out.
The biggest issue with executing on “snapshot” query downloads was that the moment the query was downloaded into a spreadsheet, the data was outdated. That is, because the order management was affected by many variables such as changes in the ship’s schedule, production upsets, and customer changes, there was a need for “real time” data for both our employees and the broker to work off of.
The project was simple in concept: map the current process, identify data inputs (both source and people), determine critical data and who should be inputting the data into a “real time” environment. The real time environ from our perspective needed to be SAP, as this was our single “truth”, and we needed the broker and all other relevant parties to work off of SAP.
When the preceding was completed, I worked closely with an IT Business Architect, who took my business needs, worked with the end users to design the solution, and then went to work with IT Technical for the technical programming.
After 4 weeks of designing and programming, we moved on to a week of testing to create all possible scenarios imaginable and the solution passed the test. Our company now has all key export order management and delivery execution data in SAP, and SAP can at the clock of a button generate real time reports for all key personnel involved in export order management.
Saturday, October 18, 2008
Welcome
Welcome to IT Project Management blog. You will find a list of interesting topics about information technology project management in this blog.
Subscribe to:
Posts (Atom)
Posts
