I started a new assignment implementing an internal community site. That got me to thinking about how are communities different from the other information sharing techniques, such as web, SharePoint, etc. A glance at a social networking site reveals a set of features and functions that are not unique or, in some cases, not very impressive. Social networks are a form of knowledge management systems. They are also content management systems. They are also information sharing and collaboration systems. We see email functions, blogs, web pages, tagging (adding Meta data), RSS (Real Simple Syndication), WYSIWYG editors, etc.
These have been around, in some form, for some time. It is not the specific features or combination of features that are unique and different. It is the context and point of view that have made social networking sites popular. With the previous tools (web pages, content management systems, knowledge management systems, file folders, etc) someone set up the hierarchy and structure based on a corporate point of view. This could be an information architect (if you were lucky). More likely, there is no defined structure and naming conventions. Even if this was easy to learn, intuitive, and everyone in the organization could quickly understand and use it, as more information and documents are added becomes a big problem.
Adding a search engine, tagging documents, and storing virtual links (or worst copies) in multiple places are only bandages. The real problem is that people think differently. Memory is experience based. People sort and categorize information by comparing to new experiences to what they already know. Social networking has tapped into that by shifting the context from a document definition or business process view to providing users with tools to add, label, and link content based on their frame of reference, themselves.
People do not think of themselves as lines on an organization chart. Almost all work is cross functional, team based, or project focused. Social networking supports this, starting with the user profile. A number of knowledge management projects in companies tried to capture the information about skills and experience. They had limited success because they started with the corporate view and labels. Then people were told to fit into the predefined slots. The user profile in a social networking system is how you think about you.
The other key to success is providing the tools to allow information to find you instead of you having to track it down. A document and data centric view makes you figure out how things are labeled, where they are stored, and if you have access to the right systems. Using tagging, RSS, and email notification, a social network provides a simple set of tools to enable information to find you. Unlike a web page or a database, where the Meta tags are not readily visible, with social networks, all the tags are visible, along with a ranking of each. That allows a user to see quickly how others categorize the content they are entering and to map those terms to terms they use.
Friday, September 12, 2008
Tuesday, May 20, 2008
The Need to Create Trust and Understanding in a Virtual Team
Every experienced Project Manager spends a significant amount of their time on communications. The communications plan (formal or not) includes who needs what types of information and which method to use. Too often, the Project Manager is forced to have too many face to face meetings. Part of that is driven by the fact that most humans obtain clues and information visually. We get clues from their facial expressions, hand gestures, and other behaviors. This information is used to assess how each person fits into the group, how similar are they to me, how competent are they, and can I trust them. The trust building and understanding happen over time. Typically, these meetings and events and not budgeted, added to a schedule, or part of a work breakdown of tasks.
Now we add the complexity of virtual globally dispersed teams. This ratchets up the communications overhead and requires a different set of skills. One significant and not fully understood effect is that people tend to under estimate these tasks. This failure to adjust and to look at it differently, too often, leads to ineffective teams and project failure. Some of the conflicts that negatively impact the virtual team can be grouped under relationships, processes, and tasks.
Relationship is the most obvious one. This covers differences in personality, language, ethnic backgrounds, cultural (including country, region, company, work group, professional, sex, etc). This lack of understanding creates misunderstandings and unmet expectations which show up as schedule and tasks issues. For teams working together over a long period of time, over six months, there are a lot of recommendations covering these. Most require embedding people into the other site for some period of time. This includes team members and the project manager, as well as management.
Processes cover how we will do the tasks or the resources required to do a task. The obvious part of this is the equipment, tools, and programs used. What is not always understood is that the management style, performance metrics, and team assignments will also create conflicts due to a lack of understanding. Even in the same company, there is no assurance that the remote teams have all of the same support, equipment, resources, etc. The culture and organizational differences at the remote sites can create radically different management styles.
Some of this also slips into the tasks category of conflicts. That difference impacts the team members ability to tolerate a different level of risks, be flexible with processes and schedules, and goal measurements and definitions. A failure to understand and explicitly agree on what the goals are, how we measure success, and all of the critical parts associated with the integration of all the tasks will lead to failure.
There is hope. A large number of research projects are focused in this area. We also have collaboration tools and methods that are improving. With Web 2.0, we have social networking tools and sites where we can share more than just documents. We can even have meetings in a virtual world. As we move from data transfer (email) to information sharing (web and phone conferences) and onto more contextually rich methods such as video, avatars, and virtual collaboration spaces, we gain more understanding and can clear away some of the potential project disasters.
Until the tools, technologies, processes, and equipment become easy and available to everyone, the Project Manager will need to step up and add even more time to the tasks of communicating effectively. The Project Manager, the team, and all of the stakeholders need to think about increasing understanding and not just moving data around. Each team member should post a five or ten minute YouTube video showing their work area and something important in their personal life. You can even expand that to include short videos about your current tasks or problem on the project. Drop those into a Wiki on the project, link them to your blog, and comment about it in your FaceBook group. We have to move beyond phones and email.
Technorati tags: project management; Web 2.0;
Now we add the complexity of virtual globally dispersed teams. This ratchets up the communications overhead and requires a different set of skills. One significant and not fully understood effect is that people tend to under estimate these tasks. This failure to adjust and to look at it differently, too often, leads to ineffective teams and project failure. Some of the conflicts that negatively impact the virtual team can be grouped under relationships, processes, and tasks.
Relationship is the most obvious one. This covers differences in personality, language, ethnic backgrounds, cultural (including country, region, company, work group, professional, sex, etc). This lack of understanding creates misunderstandings and unmet expectations which show up as schedule and tasks issues. For teams working together over a long period of time, over six months, there are a lot of recommendations covering these. Most require embedding people into the other site for some period of time. This includes team members and the project manager, as well as management.
Processes cover how we will do the tasks or the resources required to do a task. The obvious part of this is the equipment, tools, and programs used. What is not always understood is that the management style, performance metrics, and team assignments will also create conflicts due to a lack of understanding. Even in the same company, there is no assurance that the remote teams have all of the same support, equipment, resources, etc. The culture and organizational differences at the remote sites can create radically different management styles.
Some of this also slips into the tasks category of conflicts. That difference impacts the team members ability to tolerate a different level of risks, be flexible with processes and schedules, and goal measurements and definitions. A failure to understand and explicitly agree on what the goals are, how we measure success, and all of the critical parts associated with the integration of all the tasks will lead to failure.
There is hope. A large number of research projects are focused in this area. We also have collaboration tools and methods that are improving. With Web 2.0, we have social networking tools and sites where we can share more than just documents. We can even have meetings in a virtual world. As we move from data transfer (email) to information sharing (web and phone conferences) and onto more contextually rich methods such as video, avatars, and virtual collaboration spaces, we gain more understanding and can clear away some of the potential project disasters.
Until the tools, technologies, processes, and equipment become easy and available to everyone, the Project Manager will need to step up and add even more time to the tasks of communicating effectively. The Project Manager, the team, and all of the stakeholders need to think about increasing understanding and not just moving data around. Each team member should post a five or ten minute YouTube video showing their work area and something important in their personal life. You can even expand that to include short videos about your current tasks or problem on the project. Drop those into a Wiki on the project, link them to your blog, and comment about it in your FaceBook group. We have to move beyond phones and email.
Technorati tags: project management; Web 2.0;
Monday, April 21, 2008
Project Success, Measuring Outcomes VS Outputs
Web polls and surveys are still showing a high number of projects defined as a failure. People responding in the recent Computing Technology Industry Association (CompTIA) poll listed communication as the number one cause of failure. The 2007 study by Dynamic Markets Limited shows that 62% of organizations experience IT projects that failed to meet their schedule, 41% failed to deliver the expected business value and ROI, and 47% had higher-than-expected maintenance costs. The Standish Group reports that 51% of IT projects are defined as “challenged”, where they had cost overruns, time overruns, and not supportable as delivered. They also reported that 31% were cancelled outright. Gartner studies suggest that 75% of all US IT projects are considered to be failures by those responsible for initiating them.
I believe a large chunk of these failures are traceable back to the project initiation and selection process. A number of projects start on the road to failure by not having a direct link to one or more specific business strategies and goals. Even when there is linkage, how you measure success is not always clear or practical. Too often the measurements are defined around outputs, such as schedule, resources, budgets, and artifacts like documentation and lines of code. The strategic goal and the people charged with accomplishing it are interested in the outcome. Simply stated, did the project result enable the company to meet or exceed the strategic goal?
Even those that do try to connect the project with the strategy and do define and track related information, they fall into the trap of focusing solely on the historic financial measurements, such as ROI (Return on Investment) and revenue. These are limited and faulty. First, these are backwards looking and the calculations occur long after the project finishes. Any lessons learned, corrections, or improvements are hard to collect, come too late to help the project succeed, and are too easy to ignore or dismiss in the rush to finish the next project.
While every company wants to make money, directly connecting the initial guest with any revenue is difficult for projects that are not strictly working on a customer deliverable. The projects that focus on improving how the company currently does business or transforming some aspect and creating something new are too removed for a direct and immediate connection with any revenue stream. A large number of companies can not even accurately track the number of hours each person worked on any specific project. To expect a “real time” accounting which enables management and the project manager to accurately track resource and costs, let alone connect those with any future revenue, is beyond almost all companies.
The answer to increasing project success is to select measurements that are forward looking and linked to the strategic goal. One example of a company that has done this well is Southwest Airlines. The airline does not make money if a plane is sitting on the ground. The strategic goal for this is to reduce the turn around time (interval between a plane landing and taking off on the next trip). Another strategic goal is customer satisfaction, since a happy customer is more likely to use them for their next trip. One type of project that supports both of these is improving and speeding up baggage handling. The forward focused metrics for this is turn around time and lost bags. Steps that shorten the time it takes to get the aircraft back into the air and does not increase the number of bags that are missing at the destination is successful. By measuring these during the project life cycle, you have the ability to adjust and correct. You will still have projects that fail, but measuring forward provides a method to detect and correct the failure before it becomes a catastrophe.
Technorati tags: project management; business strategy;
I believe a large chunk of these failures are traceable back to the project initiation and selection process. A number of projects start on the road to failure by not having a direct link to one or more specific business strategies and goals. Even when there is linkage, how you measure success is not always clear or practical. Too often the measurements are defined around outputs, such as schedule, resources, budgets, and artifacts like documentation and lines of code. The strategic goal and the people charged with accomplishing it are interested in the outcome. Simply stated, did the project result enable the company to meet or exceed the strategic goal?
Even those that do try to connect the project with the strategy and do define and track related information, they fall into the trap of focusing solely on the historic financial measurements, such as ROI (Return on Investment) and revenue. These are limited and faulty. First, these are backwards looking and the calculations occur long after the project finishes. Any lessons learned, corrections, or improvements are hard to collect, come too late to help the project succeed, and are too easy to ignore or dismiss in the rush to finish the next project.
While every company wants to make money, directly connecting the initial guest with any revenue is difficult for projects that are not strictly working on a customer deliverable. The projects that focus on improving how the company currently does business or transforming some aspect and creating something new are too removed for a direct and immediate connection with any revenue stream. A large number of companies can not even accurately track the number of hours each person worked on any specific project. To expect a “real time” accounting which enables management and the project manager to accurately track resource and costs, let alone connect those with any future revenue, is beyond almost all companies.
The answer to increasing project success is to select measurements that are forward looking and linked to the strategic goal. One example of a company that has done this well is Southwest Airlines. The airline does not make money if a plane is sitting on the ground. The strategic goal for this is to reduce the turn around time (interval between a plane landing and taking off on the next trip). Another strategic goal is customer satisfaction, since a happy customer is more likely to use them for their next trip. One type of project that supports both of these is improving and speeding up baggage handling. The forward focused metrics for this is turn around time and lost bags. Steps that shorten the time it takes to get the aircraft back into the air and does not increase the number of bags that are missing at the destination is successful. By measuring these during the project life cycle, you have the ability to adjust and correct. You will still have projects that fail, but measuring forward provides a method to detect and correct the failure before it becomes a catastrophe.
Technorati tags: project management; business strategy;
Monday, March 10, 2008
If a Company wants a great Project Manager, why not ask for one?
I recently read an article on the Project Connections website by Cinda Voegtli, “The Medal-Worthy PMs Executives Are Desperate To Hire”. She used the metaphor of winning a gold medal at the Olympic to talk about the difference between the Good Project Manager and the Great Project Manager. After looking at recent job postings for Project Managers, she talked with company Presidents, Directors and VPs to find out what skills and abilities they valued the most in the Project Managers working for them. The results were not a surprise to me or most Project Managers. She found that most of the ads listed things such as:
While these are important, they are not the skills and abilities that the manager values the most. As she tells us, they want leaders that understand the business drivers.
That got me wondering why the mangers are not asking, screening or interviewing for these. While the basic Project Manager skills provide a baseline, those alone are not enough. In most cases, I think that the hiring manger and the rest of the team have not gotten together and determined what they want the Project Manager to do, or not to do. I have been on and participated in one of these interviews which started with one of these vague ads. Sometime the focus on bookkeeping, meetings, and data collection was due to a lack of understanding about what the Project Manager does (or should do). Sometimes a requirement from nowhere pops up due to a misalignment between the expectations of the interviewer and the manager and the rest of the team. Rarely do these interviews work out.
Where do we go from here? As a hiring manager, make sure you add and ask about the behaviors that you need in your Project Manager. If you are only asking about tools and meetings, then do not be surprised if you get great looking PowerPoint slides that only show what has happened and no recommendations or action plans to fix things. As a person on the interview team, take the time to ask about skills and behaviors that are important to the other interviewers and the hiring manager. As the person interviewing, when I get to ask my question, I always want to know about their expectations for the person in the role. Hiring managers, please take the time to give the candidate an explanation as to why they did not make it. This will help the person applying to improve their search and it will also help the hiring manager to understand if everyone’s expectations are in alignment.
Technorati tags: project management; management;
- Budgeting and data analysis skills
- Understanding and experience with related business and development processes
- Goal-Oriented, self-directed, needs little direction.
- Strong communication and customer service skills.
- Excellent documentation skills.
- Team player and able to manage others through teamwork.
- Excellent written, verbal, and interpersonal communication skills.
- Excellent organizational skills and attention to detail.
- Excellent time management skills.
- Ability to work with tight deadlines in an ever changing environment.
- Fast learner with ability to operate effectively in new environments.
While these are important, they are not the skills and abilities that the manager values the most. As she tells us, they want leaders that understand the business drivers.
That got me wondering why the mangers are not asking, screening or interviewing for these. While the basic Project Manager skills provide a baseline, those alone are not enough. In most cases, I think that the hiring manger and the rest of the team have not gotten together and determined what they want the Project Manager to do, or not to do. I have been on and participated in one of these interviews which started with one of these vague ads. Sometime the focus on bookkeeping, meetings, and data collection was due to a lack of understanding about what the Project Manager does (or should do). Sometimes a requirement from nowhere pops up due to a misalignment between the expectations of the interviewer and the manager and the rest of the team. Rarely do these interviews work out.
Where do we go from here? As a hiring manager, make sure you add and ask about the behaviors that you need in your Project Manager. If you are only asking about tools and meetings, then do not be surprised if you get great looking PowerPoint slides that only show what has happened and no recommendations or action plans to fix things. As a person on the interview team, take the time to ask about skills and behaviors that are important to the other interviewers and the hiring manager. As the person interviewing, when I get to ask my question, I always want to know about their expectations for the person in the role. Hiring managers, please take the time to give the candidate an explanation as to why they did not make it. This will help the person applying to improve their search and it will also help the hiring manager to understand if everyone’s expectations are in alignment.
Technorati tags: project management; management;
Sunday, February 03, 2008
Attended WebGuild Web 2.0 Conference
I attended the WebGuild Web 2.0 conference, 29 Feb. They expected around 300 people and were surprised to find 1200 attending. They had two keynote speakers and sessions divided into four track. I found it a mixed experience. The sessions I attended ranged from very informative to useless. A key item missing was any definition or explanation for what is Web 2.0 and what was just an improvement over the typical website and experience.
The opening Keynote was by Gil Penchina, CEO of Wikia. While the WebGuild blog posting called the talk fantastic, I would describe it as interesting. He talked about the background and philosophy of Wikia and Wikipedia. It seemed a bit “canned”. The one interesting piece was their newly launched Wikia Search. It will be worth following this effort to see if crowdsourcing and providing open access to the code and algorithms will create a search engine that can match the money and clever young folks at Google.
The second Keynote was an interview with Craig Newmark, Founder of Craigslist. As usual, Craig was very easy going and low key while still engaging. He was very open about the design and philosophy that drive the folks at Craigslist. It was good to hear someone resist the urge to jump onto the Web 2.0 bandwagon. His brief description of his current role as a customer service representative was amusing and served to emphasis the focus on the customer.
I found Steve Souders, former Chief Performance Yahoo!, and now working on web performance at Google, informative and inspiring. Most of the tips and techniques he talked about are of use to the current web site designers. It was good to hear about studies validating what the user centered design people say about page downloads. Bloated and poorly designed pages download slower and people notice. The Google study showed a loss of 20% of the traffic when the page download time increased by just one half of a second. For them, traffic equals revenue, so download speed does matter.
I attended a panel discussion on “Designing Search Friendly Sites”. The members of the panel were all very informative. There was Paul O'Brien, Marketing Director, Zvents, Lance Loveday, CEO, Closed Loop Marketing, and Charles DiFazio, Software Engineer, Google. Andreas Mueller, CTO, Bloofusion was the moderator. The comments and recommendations covered the common items, such as link backs, content, keywords, and the importance of building a site that the search engine can crawl. A big warning was issued to the designers rushing to create Web 2.0 sites using Ajax, Flash, content that requires a login, images, and multimedia applications. Charles reminded us that if the site was set up so that a blind person can access the information, then a search engine crawler will be about to find it.
The panel discussion on “Designing the Mobile Web” was not as useful for me. The members of the panel were knowledgeable and were working in the area. Julie Ask,
Vice President & Research Director, Jupiter Research moderated and the panel members were: Barbara Ballard, Founder & President, Little Springs Design, Ain Indermitte, Senior Developer Relations Manager, Nokia, and Brad Lassey, Mozilla. The take away was that mobile phones in the US are becoming more functional and that people are using them to access the web. Once again, we are reminded that people need a Smart phone or one of the high end models. As these become more affordable, companies need to plan and develop ways for the phone user to access information. Some of the current web design items, such as cookies, Ajax, and even metrics do not work well when people use the phone to access the web. The work done by Apple with the iPhone, Nokia, and Google’s Android operating system for phones were pointed to as indicators.
It was good to attend. From the topics, especially the sessions I did not attend, it appears most of what could be thought of as Web 2.0 revolved around Social Media oriented work. I believe that Web 2.0 is more than just FaceBook and YouTube. What it turns out to be, only time will tell.
Technorati tags: web design; Web 2.0; web apps; business strategy;
The opening Keynote was by Gil Penchina, CEO of Wikia. While the WebGuild blog posting called the talk fantastic, I would describe it as interesting. He talked about the background and philosophy of Wikia and Wikipedia. It seemed a bit “canned”. The one interesting piece was their newly launched Wikia Search. It will be worth following this effort to see if crowdsourcing and providing open access to the code and algorithms will create a search engine that can match the money and clever young folks at Google.
The second Keynote was an interview with Craig Newmark, Founder of Craigslist. As usual, Craig was very easy going and low key while still engaging. He was very open about the design and philosophy that drive the folks at Craigslist. It was good to hear someone resist the urge to jump onto the Web 2.0 bandwagon. His brief description of his current role as a customer service representative was amusing and served to emphasis the focus on the customer.
I found Steve Souders, former Chief Performance Yahoo!, and now working on web performance at Google, informative and inspiring. Most of the tips and techniques he talked about are of use to the current web site designers. It was good to hear about studies validating what the user centered design people say about page downloads. Bloated and poorly designed pages download slower and people notice. The Google study showed a loss of 20% of the traffic when the page download time increased by just one half of a second. For them, traffic equals revenue, so download speed does matter.
I attended a panel discussion on “Designing Search Friendly Sites”. The members of the panel were all very informative. There was Paul O'Brien, Marketing Director, Zvents, Lance Loveday, CEO, Closed Loop Marketing, and Charles DiFazio, Software Engineer, Google. Andreas Mueller, CTO, Bloofusion was the moderator. The comments and recommendations covered the common items, such as link backs, content, keywords, and the importance of building a site that the search engine can crawl. A big warning was issued to the designers rushing to create Web 2.0 sites using Ajax, Flash, content that requires a login, images, and multimedia applications. Charles reminded us that if the site was set up so that a blind person can access the information, then a search engine crawler will be about to find it.
The panel discussion on “Designing the Mobile Web” was not as useful for me. The members of the panel were knowledgeable and were working in the area. Julie Ask,
Vice President & Research Director, Jupiter Research moderated and the panel members were: Barbara Ballard, Founder & President, Little Springs Design, Ain Indermitte, Senior Developer Relations Manager, Nokia, and Brad Lassey, Mozilla. The take away was that mobile phones in the US are becoming more functional and that people are using them to access the web. Once again, we are reminded that people need a Smart phone or one of the high end models. As these become more affordable, companies need to plan and develop ways for the phone user to access information. Some of the current web design items, such as cookies, Ajax, and even metrics do not work well when people use the phone to access the web. The work done by Apple with the iPhone, Nokia, and Google’s Android operating system for phones were pointed to as indicators.
It was good to attend. From the topics, especially the sessions I did not attend, it appears most of what could be thought of as Web 2.0 revolved around Social Media oriented work. I believe that Web 2.0 is more than just FaceBook and YouTube. What it turns out to be, only time will tell.
Technorati tags: web design; Web 2.0; web apps; business strategy;
Thursday, January 17, 2008
The Future of Web Apps, Panel Discussion at the monthly WebGuild Meeting
There was an interesting panel discussion last night at the WebGuild monthly meeting. John Rowell (Chief Technology Officer, OpSource), Brad Neuberg (Developer Advocate, Google Gears), Raju Vegesna (Evangelist, Zoho), and Bill Scott (Director of UI Engineering, Netflix) gave their impressions on were we currently are on the web and the trend toward Web Apps. The trend over the last two years has been MashUps, where you build a Web App that uses information and the infrastructure of a larger application. Two common examples are small Web Apps that running inside Facebook and Web Apps that use data from Google Maps.
This trend has been gaining ground under the term Software as a Service (SaaS). OpSource and AdventNet's ZoHo are good examples. OpSource is targeting the developers at both small and large companies. They provide the infrastructure to support the Web App. The companies can now focus their resources on the product and let OpSource worry about servers, storage, security, backups, extensibility, and all the other large, complex issues that come with owning the infrastructure.
Adventnet's ZoHo product line implements both the infrastructure and the Web Apps sitting on it using this separation approach. Using a common infrastructure, web App teams only need to focus on the features and functions of their products. Each product is light weight and the development is customer driven. They only add features and functions when they are requested by the customer. The infrastructure team creates and maintains the support systems. This enables them to roll out new Web Apps and make changes to the existing Web Apps quickly.
Google is a big player in the move to open source tools and applications that make it easier to use the web. Google Gears is an application that enables you to use the data from an on-line service when you are not on-line. Basically it creates a database on the client system used to cache the data from the on-line service. When your system does connect back to the on-line service, the data is automatically synced. While a little different, it proves a developer with a toolkit to create an App that uses the infrastructure of an existing on-line service, such as Google Maps, without being part of that company.
At first, Netflix's interest in this area was puzzling. Their focus is matching movies to customers and enhancing your movie experience. They have a huge database about movies and their customers. Opening that up to outside Web App developers is not the driving factor. With well over seven million subscribers, the infrastructure extensibility and the ability to create and deploy new features are complex problems. Redesigning the system to follow the model of separating the infrastructure from the Web Apps will help them handle the current and future demands. It will also make it easier for them to move into direct distribution.
For the Web App developers and the companies that own both the infrastructure and the Web Apps, this is a great move. As on-line services and applications grow, the infrastructure complexity, cost, and extensibility have become serious issues. This model is not new. For years, the satellite designer had used a common data bus that allowed different components to plug-in and communicate. We are now seeing the concept of the web as a big data bus start to drive the thinking. The issues of costs and monetization are quietly being discussed inside the major on-line service providers. They are creating APIs to allow controlled access to their data and functions. The trend of Web App developers creating products without large and expensive infrastructure investments will continue to grow. At some point, the people spending huge sums of money on the infrastructure will a way to collect payment form those developers. If you have a closed system, like Facebook, that becomes easy. The current movement is toward more open systems and not developing more closed gardens. It will be interesting to see how the usage and payment are tracked and how the costs are allocated.
Technorati tags: web design; software management; web apps; business strategy;
This trend has been gaining ground under the term Software as a Service (SaaS). OpSource and AdventNet's ZoHo are good examples. OpSource is targeting the developers at both small and large companies. They provide the infrastructure to support the Web App. The companies can now focus their resources on the product and let OpSource worry about servers, storage, security, backups, extensibility, and all the other large, complex issues that come with owning the infrastructure.
Adventnet's ZoHo product line implements both the infrastructure and the Web Apps sitting on it using this separation approach. Using a common infrastructure, web App teams only need to focus on the features and functions of their products. Each product is light weight and the development is customer driven. They only add features and functions when they are requested by the customer. The infrastructure team creates and maintains the support systems. This enables them to roll out new Web Apps and make changes to the existing Web Apps quickly.
Google is a big player in the move to open source tools and applications that make it easier to use the web. Google Gears is an application that enables you to use the data from an on-line service when you are not on-line. Basically it creates a database on the client system used to cache the data from the on-line service. When your system does connect back to the on-line service, the data is automatically synced. While a little different, it proves a developer with a toolkit to create an App that uses the infrastructure of an existing on-line service, such as Google Maps, without being part of that company.
At first, Netflix's interest in this area was puzzling. Their focus is matching movies to customers and enhancing your movie experience. They have a huge database about movies and their customers. Opening that up to outside Web App developers is not the driving factor. With well over seven million subscribers, the infrastructure extensibility and the ability to create and deploy new features are complex problems. Redesigning the system to follow the model of separating the infrastructure from the Web Apps will help them handle the current and future demands. It will also make it easier for them to move into direct distribution.
For the Web App developers and the companies that own both the infrastructure and the Web Apps, this is a great move. As on-line services and applications grow, the infrastructure complexity, cost, and extensibility have become serious issues. This model is not new. For years, the satellite designer had used a common data bus that allowed different components to plug-in and communicate. We are now seeing the concept of the web as a big data bus start to drive the thinking. The issues of costs and monetization are quietly being discussed inside the major on-line service providers. They are creating APIs to allow controlled access to their data and functions. The trend of Web App developers creating products without large and expensive infrastructure investments will continue to grow. At some point, the people spending huge sums of money on the infrastructure will a way to collect payment form those developers. If you have a closed system, like Facebook, that becomes easy. The current movement is toward more open systems and not developing more closed gardens. It will be interesting to see how the usage and payment are tracked and how the costs are allocated.
Technorati tags: web design; software management; web apps; business strategy;
Friday, November 16, 2007
Changing the Metaphor of Work from Machines to Humans
I heard a great talk by Mark Morgan at the monthly meeting of the Northern California Chapter of the Association of Strategic Planning yesterday. He based his talk on the new book, Executing Your Strategy, by Mark, Dr. Raymond E. Levitt, and William A. Malek. Using the Strategic Execution Framework (SEF) diagram he pointed out the interconnections and dependencies between the different imperatives in a company.
He started by pointing out how we talk about the work that goes on in a company. The terms used in the books, classes, and consulting have their roots in the work by F. W. Taylor back in the 1900s. That was the Industrial Revolution. Company management process was put stuff into the machine, make the machine more effective and efficient, and sell the stuff coming out cheaper than the other company does. The major component of work today, especially in the United States, is people.
We can find a number of people that specialize in one or two of the different functional bubbles on the SEF diagram. They have studied, consulted, and written about their functional bubble. Where management at companies gets into trouble is that this is a dynamic continuous system, not a set of hierarchical points. The arrows connecting the bubbles on the SEF diagram, especially across what Mark refers to as the six imperatives, Ideation, Nature, Vision, Engagement, Synthesis, and Transition, often are overlooked. As any experienced software programmer will tell you, the interfaces are the critical problem areas.
The driving force behind activities in companies today, even manufacturing companies, are interactions between people, more than between machines. To succeed, all of the bubble functions have to be in alignment. Communications and actions have to work together. This view of the company as a system is what resonated with me. It is critical for everyone to look at the entire system, the ecosphere, inside the company and the alignment of each of the parts. Looking back, I can see that this was what drew me to get an MS in Systems Management, and to being a Project/Program Manager.
It also explains some of the problems I have encountered on engagements to create systems to move strategy through portfolio, programs, and into projects. Optimizing only one area will not improve the implementation of the strategy. If we do not align all of the parts, we will not move forward.
Technorati tags: project management; program management; management; business strategy;
He started by pointing out how we talk about the work that goes on in a company. The terms used in the books, classes, and consulting have their roots in the work by F. W. Taylor back in the 1900s. That was the Industrial Revolution. Company management process was put stuff into the machine, make the machine more effective and efficient, and sell the stuff coming out cheaper than the other company does. The major component of work today, especially in the United States, is people.
We can find a number of people that specialize in one or two of the different functional bubbles on the SEF diagram. They have studied, consulted, and written about their functional bubble. Where management at companies gets into trouble is that this is a dynamic continuous system, not a set of hierarchical points. The arrows connecting the bubbles on the SEF diagram, especially across what Mark refers to as the six imperatives, Ideation, Nature, Vision, Engagement, Synthesis, and Transition, often are overlooked. As any experienced software programmer will tell you, the interfaces are the critical problem areas.
The driving force behind activities in companies today, even manufacturing companies, are interactions between people, more than between machines. To succeed, all of the bubble functions have to be in alignment. Communications and actions have to work together. This view of the company as a system is what resonated with me. It is critical for everyone to look at the entire system, the ecosphere, inside the company and the alignment of each of the parts. Looking back, I can see that this was what drew me to get an MS in Systems Management, and to being a Project/Program Manager.
It also explains some of the problems I have encountered on engagements to create systems to move strategy through portfolio, programs, and into projects. Optimizing only one area will not improve the implementation of the strategy. If we do not align all of the parts, we will not move forward.
Technorati tags: project management; program management; management; business strategy;
Subscribe to:
Posts (Atom)
