Skip to content

Web 2.0 for Project Management: Team Headquarters

1 December 2011, 7:14 am

Effective collaboration is the result of good communication and coordination of work. So far this series has been mostly about communication tools that appeal to small teams who don’t have much formal process in the way they approach project management. Teams like that want just enough structure to organize their work without introducing much process overhead. The strength of tools like BaseCamp and OneHub is effortless delivery of functions that promote good communication without much need to formalize the way work gets done. A lot of projects happen in that kind of setting but it can be pretty casual. As organizations get larger and the number of projects in the mix increases so does the need to pay attention to business processes. A hidden gem that addresses work coordination dimension is TeamHeadquarters (THQ) from Entry Software.

THQ offers the promise of one-stop shopping for service tickets, project management and time entry functions. It is intended mainly for IT help desks and other service organizations where day-to-day handling of incidents and service requests is knit tightly with managing a portfolio of projects. Organizations like that may execute more than 100 small projects in a year, with 20 or so in-flight at any given point in time. It is a fast-paced environment where the ability to schedule, plan and track activity is important to everyone involved. In small and mid-sized organizations, where the people working in projects are often the same people responsible for delivering on service tickets, projects and day-to-day service work compete constantly for attention. At the same time, the sheer volume of work requires team members to have easy, lightweight ways to communicate with each other.

Open up THQ, and the first impression is that a lot of time and care have gone into the user interface. The expandable menus at the left of the screen control a large content pane that occupies centre stage. Functions selected within the content pane (e.g., create new task) launch forms that are well-organized, easy to use and consistent in the way they present information. It is easy to forget that this a browser-based application delivered via software-as-a-service.

Team Headquarters Menu

Spend some time exploring and it also becomes evident that a lot of service desk best practices are built into the product. Although not promoted as a prescriptive “ITIL in a box” solution, the capability is there to support the kinds practices that service organizations are usually looking for when they are implementing the ITIL service management framework. Just as an example, service tickets include pre-built work queues that make it easy to keep track of the status of work-in-process with simple visual indicators that show when service level commitments are at risk. The same view shows at a glance which tickets have not been assigned.

THQ Help Desk

The interactive Gantt chart is worth special mention. Launched from a right-click menu once a project is displayed, the project task list presents in a traditional Gantt chart format. Drag or stretch the bars and the task scheduling information updates to show the effects of the changes. Save the changes made by manipulating the chart and they become a permanent update to the planned schedule.

THQ Gantt

An innovation in the way that THQ organizes information is “One Task List”, which attempts to dissolve the distinction between tickets and project assignments for team members. The simple underlying notion is that work is work, it can be assigned to individuals as discrete tasks, and tasks need to be completed by specific dates. By connecting the tasks to higher level plans driven by delivery commitments and service level objectives the Task List becomes a medium for bringing operational and project concerns together instead of setting them up in competition with each other.

Notes and Documents are the main communication tools. Anyone who has worked in a service desk setting should recognize the value of notes on a ticket as a running narrative of what has been done and what needs to happen next. As Problem Management bundles together tickets for recurring problems, notes can also be a rich source of planning information to help determine the scope of projects that can provide lasting improvements in the production infrastructure.

Document management functionality operates in two ways. First, a simple upload provides the ability to attach documents to any ticket, task or project. As well, documents can be uploaded into libraries for creation of a shared knowledge base. A search function gives the ability to search the entire site for keywords and phrases.

Few of us can admit to getting excited about a time sheet but organization who need time control also know that time entry has to be easy to use or people simply won’t do it. The time sheet in THQ is simple and straightforward to use with an entry list that generates automatically from the task list. As well, any work times that have been entered on service tickets will populate into the time sheet automatically.

Limitations that I noticed during evaluation were mostly minor:

  • Internet Explorer as the only supported browser (a trade-off to enable a feature-rich user interface)
  • Opportunities to customize the look and feel of the site are somewhat limited
  • Interface with MS Project is import only

Getting started with THQ is a project in itself. Beyond the free 30-day trial evaluation, implementation involves populating the database with information about the organization (e.g., users, groups, ticket categories), a must do step to get started with any integrated service desk and project management solution. A typical implementation project is 8-12 weeks, which is similar to my own experience in implementing service desk solution sin mid-sized organizations. Entry Software offers a package of training and support services to assist organizations who want to help in configuring the product to suit their own needs.

For more than a decade, Entry Software has been quietly building a solid customer base among mid-sized organizations in health care, transportation and other service industries. They offer a convincing value proposition to organizations that are big enough to need some formal process that brings service and project work together. TeamHeadquarters is positioned to provide the needed structure without the overhead of hosting and integrating separate systems for service desk, project management and time control. With more than 5,000 users in production, it still isn’t quite big enough to be included in the Gartner evaluation of enterprise service desk solutions. That said, the functional footprint goes well beyond many mid-market help desk solutions. At $360 / month for a 10-user license (unlimited tickets and projects), THQ delivers a range of functions that would simply be out of reach for a mid-sized organization if they had to be acquired through separate applications hosed in-house.

Overall Rating
(out of 4 )
Team Collaboration
Transactional
Project Communication
Getting Started  
Customize Look and Feel
Ongoing Cost
Features
Can’t Do It
Custom (Major)
Custom
(Minor)
No Problem
Announcements X
Shared Calendar X
Shared Task List X
Team Discussion X
Assign Project Tasks X
Email Notification X
Syndication X
Progress Reporting X
Track Issues X
Track Risks X
Time Entry X
Track Earned Value X
Multi Projects in 1 site X
Roll-up multi projects X
MS Project Interface X
Word, Excel Interface X
Comment

Web 2.0 for Project Management: Basecamp

22 October 2011, 8:15 am

With over 5 million subscribers world-wide, Basecamp rivals MS Project for most-used project management software. Yet these two tools offer very different capabilities. MS Project has a well-established place in the Project Manager’s tool kit as an aid to managing schedules and budgets. Basecamp focuses on team collaboration. This post takes a closer look at some of the features that have made Basecamp so popular.

Basecamp from 37Signals is part of a suite of software-as-a-service tools for team communication. Aimed primarily at small and mid-sized organizations, this Chicago-based provider sets out to provide “frustration-free web-based apps for collaboration, sharing information, and making decisions.” The other tools in the suite include Highrise for contact management, Campfire for instant messaging and Backpack as an intranet portal.

Open up Basecamp and you will find a site that is inviting, uncluttered, intuitive, and all about communication. To find out how easy it is to use I tried out the free plan (1 project, unlimited users, 2 Writeboards, 10 MB File Storage). The 60-second sign-up took exactly that, and almost immediately I was able to start building a project plan.

The home page presents a dashboard view that gives an at-a-glance summary what’s going on in the projects in your site. Throughout the rest of the site Basecamp focuses on simple, basic ways of doing things. Navigation is very clean with big, easy-to-read tabs at the top of the screen to switch between different types of project information. For example, the “To-Dos” tab shows outstanding To-Do items assigned to me. Click on the “Calendar” tab and the default view shows items that are due within the next 6 weeks.

As a long-time MS Project users, I was curious about how Basecamp handles schedules. What I found  is best described as management by milestones. A milestone can, of course, be anything the team decides it should be. By extension, project activities are the things people do in order to get to a milestone. Rolled out over an entire project, the Gantt chart view from MS Project presents itself in Basecamp as a series of To-Do lists punctuated by milestones.

Basecamp milestone list.

Creating a milestone in Basecamp is easy, and the dialogue enforces the idea that it’s something to be achieved by a particular date and that someone needs to own. Once a milestone has been added to a project, adding activities to the schedule is simply a matter of creating a To-Do list that attaches to the milestone. Each To-do item is them given a due date and assigned to a team member.

Basecamp create milestone

Wiki pages have become a popular way for project teams to collaborate on a document, especially when they don’t have a lot of opportunity for face-to-face meetings. Basecamp offers the “Writeboard”, which is a page equipped with simple text editor where team members can work together on a shared document.

Overall, Basecamp does a good job of providing a simple, lightweight way to enhance many aspects of project communication with a minimum of training and set-up overhead. To some eyes, the emphasis on simple ways of doing things may go a bit too far. Things that someone looking for an “enterprise” solution would probably see as limitations include:

  • Text editor in the write board lacks most of the rich text editing features that we tend to take for granted.

  • Ability to store and organize documents includes the ability to sort them by name and other attributes but only one category tag can be applied to each document. What happens in projects that generates a lot of documents?

  • Time-tracking functionality is very easy to use. But the problem with time-tracking in general is that it’s easy to ignore. Would people actually use it consistently enough to obtain reliable cost data?

  • Cannot make a Gantt chart representation of a project schedule. Projects with complex dependencies could be difficult to set up and control.

  • Data export from the site is in a single XML file. It’s easy to produce but plan on a lot of effort in deciphering the file if you want to do anything with the data.

Cost for subscribing to Basecamp depends on how many projects are in your portfolio. At $49 per month the “Plus” plan gives the capability to create 35 projects and provides 15 GB of file space for an unlimited number of users.

If I had to sum up Basecamp in one phrase it would be “Project Management Light”, and that’s not a bad thing at all. These days a lot of projects get done by small teams of multi-talented people with limited time and little appetite to apply a lot of formal project management process to their work. Teams like that often work on short planning horizons with little need for a robust scheduling tool. Basecamp can help that kind of team work together, communicate effectively and share project management responsibility. Judging from the feedback on Basecamp’s “Customer Wall” they have found a lot of people who agree that Basecamp can deliver a lot of value.

Overall Rating
(out of 4 )
Team Collaboration
Transactional
Project Communication
Getting Started  
Customize Look and Feel
Ongoing Cost
Features
Can’t Do It
Custom (Major)
Custom
(Minor)
No Problem
Announcements X
Shared Calendar X
Shared Task List X
Team Discussion X
Assign Project Tasks X
Email Notification X
Syndication X
Progress Reporting X
Track Issues X
Track Risks X
Time Entry X
Track Earned Value X
Multi Projects in 1 site X
Roll-up multi projects X
MS Project Interface X
Word, Excel Interface X
Comment

Web 2.0 for Project Management – OneHub

17 July 2011, 7:52 am

Imagine this scenario. Your project team is spread out across several organizations. You need a place to put files and share a task list, a calendar and maybe a wiki. Sound familiar? OneHub might be what you’re looking for.

The home page makes a simple, straightforward claim: “Secure, fast and easy-to-use file sharing for any size business. Manage projects, share files and collaborate with others.” Open it up and you will find a site that does just that, no more and no less. In fact it offers most of the basic functionality that a SharePoint project site would have. The big difference is the almost completely effortless setup required to get a secure, customizable workspaces for collaboration and document sharing.

The entry level set-up is free. In about about 5 minutes you can build a virtual workspace with 2 GB of storage and a range of functions that you select from a series of pre-built widgets in the site template provided. Select your own colour scheme, add a logo to dress it up and there it is, ready to use. From the administration dashboard you are now ready to issue email invitations for people to join your Hub (and also set permissions for what they can do when they get there). There is no limit on the number of people who can use a hub.

So how does OneHub stack up in our evaluation? The user interface is easy to read, and intuitive to navigate. The available widgets include the kinds of things you would expect to find in a collaboration workspace:

  • Document Management
  • Task List
  • Calendar
  • Discussions
  • Wiki
  • Activity Tracker

Document management functions are strong with an easy one-click upload function, built-in version control and the ability to organize files into folders.

The task list can be used to assign work to team members, and they will receive email notices when the work is assigned and again when it’s due. Linking the calendar to the task list provides an informal way to do scheduling.

If you want to maintaining an Issue List or a Risk Register as part of your project documentation then you will probably have to do that in a document and upload it to the site. Alternately, you could make use of the Wiki page, which a great place for teams who are spread out to work on a document together.

OneHub was built for collaboration, not for formal, structured communication so it’s not very surprising to see some weaknesses there. For example, the task list enables assignment to a team member but the only progress report available is marking it complete. Ability to track issues and risks is also absent, although either the document management functions, the Comments widget or the Wiki could be adapted for that purpose. Although the task list and calendar provide some basic scheduling capability the ability to do formal schedules (e.g., Gantt charts) is absent. Time reporting is also absent, as is the ability to roll up to a high level view of what’s happening across an entire portfolio of projects. Although it is very easy to upload office documents to a OneHub site, there is no direct integration to any desktop applications.

Cost depends on how many projects are in your portfolio. OneHub offers a variety of price plans to choose from depending on the number of hubs and the amount of file storage space you need. At $99 per month the “Team” plan gives the capability to create 25 workspaces and 25 GB of file space for an unlimited number of users.

Overall OneHub looks like good value and well worth a close look for anyone looking for a way to improve project team communication. Based in Bellevue WA, the company is in its fifth year of operation claiming over 100,000 users for the site and over 700 paying customers. Financing looks respectable for the long haul http://onehub.com/about/news/pr-20091029 . OneHub has all appearances of a “small and steady” kind of company that plans to be around for a while to take care of their customers.

Overall Rating
(out of 4 )
Team Collaboration
Transactional
Project Communication
Getting Started  
Customize Look and Feel
Ongoing Cost
Features
Can’t Do It
Custom (Major)
Custom
(Minor)
No Problem
Announcements X
Shared Calendar X
Shared Task List X
Team Discussion X
Assign Project Tasks X
Email Notification X
Syndication X
Progress Reporting X
Track Issues X
Track Risks X
Time Entry X
Track Earned Value X
Multi Projects in 1 site X
Roll-up multi projects X
MS Project Interface X
Word, Excel Interface X
Comment

SharePoint Maturity Model and Project Management

25 June 2011, 12:07 pm

One more word about SharePoint. A wise man once said “a fool with a tool is still a fool”. Changing behaviour is at the heart of any organization’s effort to introduce new tools, and SharePoint is no different than any other technology in that respect. SharePoint is a medium for building a project management information system but there has to be a basic understanding of what good project communication looks like for the effort to do any good.

Recently I came across a presentation by Sadalit Van Buren about her work in documenting a SharePoint Maturity Model. To make a long story short the model provides a way for organizations adopting SharePoint to see where they are in relation to other organizations and some best practices. Intended to guide technology adoption strategy, the framework explores current practices in each of 12 areas of capability and provides as systematic way to assess use of the technology on a 5-step scale  with each step representing a higher level of standardization and optimization:

  • 100 – Initial
  • 200 – Managed
  • 300 – Defined
  • 400 – Predictable
  • 500 – Optimized

So, you may ask, what does this have to with project management? For starters, despite the promise that SharePont offers for improving communication and supporting virtual project teams, people locked in email and file shares can just as easily ignore the shiny new technology as use it. They need to see value in doing something differently. The leadership challenge rests in understanding the  gap between what people are doing and the vision for what they should be doing. If the gap is perceived as too big they might not bother at all without some help and encouragement.

Maturity models like CMM, OPM3, and (now) SPMM help managers understand the gap and set realistic goals for standardization and continuous improvement by providing benchmarks that give insight into  where a group is in their journey to develop competency. Guideposts that aid planning how (and how far) to move forward can go a long way toward successful adoption.

Comment

SharePoint for Project Management

26 February 2011, 2:19 pm

So, what happened to 2010. The short version is that I did the research, and it has been an interesting journey. Those who attended last year’s PMI Southwestern Ontario Spring Symposium heard part of the story. The next several posts will tell the rest with each one take an in-depth look at one solution.

Let’s start with SharePoint. It’s showing up in a lot of places and, simply put, it has a lot to offer project teams. SharePoint has a number of attractions, and high on the list is its facility for managing lists. That is useful to project teams because they live in a world of lists — activity lists, issue logs, risk registers and many more. SharePoint also offers lots of built-in components that enable wiki’s, blogs and document management, the more unstructured part of project communication. In short, all of the building blocks for a first rate project information system are there.

There, to be sure, but not always ready to use. SharePoint is a tool kit, not a packaged Project Management Information System. The effort required to get started is not large and the building blocks are there to enable a high level of project team collaboration. For the full story on how to do it, check out the book (and web site) from Dux Raymond Sy, which gives a step-by-step guide to building a working PM information system from WSS (the “free” version of SharePoint that comes with Windows Server). With some work you can expect to build a project team site that will provide:

  • Single Point of Access
  • Role-Based Security
  • Shared Lists
    • Task List
    • Issue Log
    • Risk Register
  • Document Management
    • Charter, Project Plan
    • Team Work Product
    • Built-in Version Control
  • Team Collaboration
    • Announcements
    • Calendar
    • Contacts
    • Discussions
    • Wiki
  • MS Office Integration

If your organization is already making an investment in SharePoint, project collaboration is a great place to get quick value from your investment. You will need to start by spending time with your IT folks in order to understand what the rules of the road are for creating and administering sites in your organization. You will also need to invest some time up-front with configuration and testing before you are ready to use the site in your projects. Once you have a template and you know who is going to be using your site, it only takes a few minutes to expand it to include more projects and they start up. Even if your organization isn’t planning to install SharePoint it may still be an option. Many web hosting services will provide SharePoint hosting based on the WSS platform. About $60 per month should get enough space to host a project information system that will do quite a lot.

On the other hand, there are some caveats. The first is to remember that because SharePoint is a do-it-yourself kit you will have to invest some time and effort getting it to look and behave the way you want it to before you can share it with your project teams. You will also need professional help in order to get beyond the basics. SharePoint makes it very easy to create a new web site for each project but it’s not so easy to get a top-down view of all of the projects in your portfolio. Web parts to do that are available at a relatively modest cost but you will go through some technical hoops in order to install and configure these extra components if you need them. Finally, remember that the integration between SharePoint and MS Office is very good but it does not include MS Project. If you use MS Project now, sharing project information with people who do not have it will continue to be challenging.

Report Card:

SharePoint (WSS 3.0) for Project Management

Overall Rating
(out of 4 )
Team Collaboration
 

Transactional
Project Communication
Getting Started
Customize Look and Feel
Ongoing Cost
Features
Can’t Do It
Custom (Major)
Custom
(Minor)
No Problem
 

Announcements

 X
Shared Calendar

X
Shared Task List X
Team Discussion X
Assign Project Tasks X
Email Notification X
Syndication X
Progress Reporting X
Track Issues X
Track Risks X
Time Entry X
Track Earned Value X
Multi Projects in 1 site X
Roll-up multi projects X
MS Project Interface X
Word, Excel Interface X
Comment

Web 2.0 for Project Management – The Product Research Challenge

27 February 2010, 12:31 pm

If Web 2.0 tools offer the promise of better project communication, what does “better” look like? Answering that means considering two broad dimensions of project communication that point in opposite directions. In one direction there’s collaboration where the priority is the individual experience of finding and sharing information. In that context “better” looks like one-stop-shopping for project information in surroundings that promote collaboration by encouraging people to engage in discussion through annotations and comments — in other words, the kinds of personal interactions that social media support. Looking the opposite way we find Enterprise Project Management systems where the priority is the transactional work of project execution. There, communication is far more structured and “better” means making it easy to track task assignments, report progress, submit time sheets and manage lists like issue logs or risk registers.

My research challenge for the balance of 2010 is to look at the marketplace to see if there is a service provider out there who can satisfy both of these project communication priorities effectively at a price that a small or mid-sized organization can afford. I will be visiting (and signing up with) a series of providers with a software-as-a-service (SaaS) offering for project management. I will be looking at them from the perspective of what the tools let people do, and how well they support both formal and informal project communication. I’m also interested in the business experience of working with the provider, so in addition to the functional aspects I will be exploring some basic management questions:

  • How easy it is to get started?
  • How easy is it to customize the look and feel of the site?
  • How much does it cost to get started and to maintain information with the provider over time?
  • Who is the provider, where are they and what it’s like to do business with them?
  • How stable is the provider (will they still be around in five years)?
  • What information security risks should I worry about?
  • How easy is it to retrieve project data from the site if I decide to change my project records management strategy?

From this I hope to draw a sketch of fit (and gaps) that different organization would likely experience with each of the providers I examine. Beyond that it’s up to you to judge the value of the information. I have a list of providers that I have started with, and the first review will be out in a week or so. The rest will follow as the year unfolds. I look forward to your comments and your suggestions.

Comment

Web 2.0 for Project Management – Why Email Isn’t Enough

3 February 2010, 2:47 pm

My last post about Web 2.0 tools for project management led to two lines o f conversation with some colleagues. The first was about and how poor communication about requirements can lock in design mistakes early in Design / Build projects and lead to major rework costs later on. The other was about why we need to bother trying to get people to learn how to use a new communication medium. We all use email every day; isn’t that enough?

Three “C” words tie these threads of conversation together: Communication, Coordination and Collaboration. Not a particularly original phrase, I admit — Lotus Notes jumped on it a long time ago to promote its (then new) groupware capabilities. Nevertheless, making it easy for people to work together is one of the cornerstones of project success. Writing in the Project Communications Bible, Bill Dow and Bruce Taylor cite communication deficiencies as the leading root cause of why projects fail. They go on to spend more than 800 pages in a practical exploration of how to apply good project communication practices to all aspects of project management.

Michael Sampson argues that Collaboration in the context of project management just summarizes key ideas conveyed by the other two “C” words. In his view, a good collaboration means that the project participants communicated well, debated openly and worked together to achieve a set of objectives that everyone understood.

Applied to any Design / Build project the most critical collaboration among project stakeholders is arguably requirements definition. We all know (and the PMBOK reminds us) that the ability for stakeholders to influence the final product of a design/build project is highest at the beginning and diminishes exponentially over the life of the project. The mirror-image is the cost of accommodating changes, which increases over the life of the project at a rate similar to the decrease in stakeholder influence. That is as true for putting up a building as for developing a piece of software. Providing a forum that encourages a high level of end user involvement early in the project is a strong measure for preventing a host of problems (not to mention risk of rework) later on. Effectiveness of that involvement can be judged, at least in part, by how well it promotes open debate about requirements.

In an ideal world we would have lots of opportunity to bring key stakeholders together in a series of meetings that would provide the forum for debate about requirements. Design team could go happily on their way, confident that they had an accurate set of requirements to build from. Sadly, we don’t live in an ideal world so we look for technology to help the project communication process. The first place we usually turn is still email because it’s easy to use, it gets the job done and we feel like we have a certain amount of control over it.

The problem with email in projects stems from the way people interact with it. Partly, it’s volume — email contributes a big chunk of the information overload that we all struggle to cope with daily. It’s easy for important project communication to get lost in the flood. (How many messages do you have in your inbox, how many are unread, and how many are messages that you actually wanted to receive?)  The other problem is Information Channeling. Two individuals may start up a private discussion thread over email and actually feel that they are making a positive contribution to the project. However, that discussion may exclude key stakeholders, either consciously or unconsciously. Over time, people may move in and out of the thread through the CC list or the thread may be lost entirely if a key individual leaves the project or the organization. Lars Ploughmann suggests the following scenario for what could easily happen to a message about an important project change that has been approved when it is sent to 10 people via email:

  • 9 people read the email
  • 8 people file the email (in their private folders, thereby duplicating effort)
  • 7 people are interrupted in their work or thoughts when the email arrives
  • 6 people will never be able to find the email again
  • 5 people didn’t actually need to know about the change
  • 4 people joining the project in the next phase wouldn’t have received the email
  • 3 people will be able to find the email again, should they need to
  • 2 people will check back to the email at a later date when they need the information
  • 1 of them will understand the email in context, be able to find it at a later date and action it

Web 2.0 tools offer the promise of better project communication, and more effective collaboration among stakeholders who don’t get to meet face-to-face nearly often enough. The challenge is that adopting the tools has far more to do with human behaviour than technology.  Research evidence and common sense both suggest that if technology doesn’t fit the organization and people don’t understand it they won’t use it. The outcome with social media could be just as ineffective as Lars Ploughman’s scenario, just transferred to a different technology platform.

High quality tools matter but the focus of attention should be what the tools let people do. If the goal is better collaboration then it should be easy to find all of the project information in one place and to engage in discussion through annotations and comments. As well, the pace of change needs to match people’s capacity to absorb it. People who are already accustomed to using sites like Facebook and Twitter know intuitively what to do. Others may need some guidance. All will need some time to judge the quality of the content, how easily they can participate in discussions, and how that affects project outcomes in the long run.

Comment

Adopting Web 2.0 PM Tools – A Question of Balance

5 January 2010, 2:29 pm

PM Maturity Model

My last post began to make a case for Web 2.0 tools as something that can give project teams access to collaboration and information sharing capabilities that many organizations have viewed as simply out of reach. One of the risks in embracing a new technology is that it may consume a lot of time and resources doing well, something that wasn’t worth doing at all. After all, Project Managers often struggle with just getting things done, never mind the challenges of learning new software tools. Why is information sharing and social networking software worthy of a Project Manager’s attention?

Implicit in a discussion of project team collaboration and information sharing tools is the idea of a Project Management Information System (PMIS). Functionally, that’s the set of tools (and I use the term in its broadest sense) that project managers use to organize project information. The information can include all of the formal project management documents (e.g., charter, project plan, change requests) as well as emails, schedules, forms status reports, meeting minutes and other documents that chronicle the life of the project. The information tends to exist in a variety of different formats, and individual documents tend to have a short working lifetime. All organizations have some kind of system but there is great variation in terms of how explicitly it is recognized, how much structure it imposes and how consistently it is adopted. The reality is often no formal PMIS that anyone would recognize as such.

In fact, there is a strong temptation to believe that’s good enough.  The usual focus for Project Management software is something to help Project Managers with planning, tracking and reporting on project activity, and desktop PM software does that well. But suppose the project team is charged with the business end of innovation — developing new products and services. Projects like that carry lots of pressure to respond to changing circumstances quickly with informed decisions. And what if the project team members rarely get a chance to meet face-to-face? It doesn’t take too long to make a case that the day-to-day work of project teams can be improved by giving them better access to project information when they need it and wherever they happen to be.

Unfortunately, there is no simple formula for picking the right software or the right implementation path. Much depends on where the individual organization is in their project management maturity journey, which is often not the linear progression we would like to think it is. For many organizations, embracing better project management tools advances more in the fashion of technology adoption in the marketplace. Early adopters who see value in something new and are willing to accept some trial-and-error are likely to blaze the trail, absorbing new tools in the way their teams work long before the tools become mainstream. Likewise, small organization operating at a simple “Do-It” level of maturity can gain almost immediate benefits with little cost by just using good practices that are embedded in freely available, web-based tools. At the other end of the spectrum, organizations that have already reached a high level of standardization can still benefit when project team have access to improved information sharing capabilities.

Adopting the tools becomes a question of balance. Like any knowledge-based capability, organizations improve their collective project management expertise in cycles that balance informal knowledge gained through experience with structured knowledge codified in templates, procedures and processes. Each cycle of the learning process should be adding just enough structure to make a difference at a practical level and to carry the organization’s strategic priorities a step forward.

Comment

Small and Mid-Sized Enterprise 2.0

21 December 2009, 12:50 pm

Enterprise 2.0 is gaining attention as a way to describe the way that social media tools are changing the way that people communicate at work. What (if any) relevance does that have for small and mid-sized organizations?

If you perceive a hint of déjà vu it’s probably a memory of things we were saying a decade or so ago when the web was catching on as a mainstream business communications medium. The promise then was that easier information sharing and collaboration were going to transform the way that people worked. Individually we now use the web every day, but regardless of size a lot of organizations remain as tightly siloed as ever in the way they manage information.

Cut away some of the hyperbole and the value proposition that authors like Andrew McAfee and Matthew Fraser & Soumitra Dutta are calling Enterprise 2.0 is this: by making it easier for people to communicate with each other, Web 2.0 tools (i.e., wikis, blogs and other social media) help people to be better informed, react faster to changing circumstances and make better decisions. They go on to say a lot about how this plays out in large organizations, and they cite examples of how adopting the technology has helped information workers overcome some of the complexities that go with being big.

Interesting stuff, to be sure, but it may beg a “so what” response for the other half of the information worker population, the ones who work in Small and Mid-sized Enterprises (SME).  According to Industry Canada, that’s roughly the proportion of employees who work in SME organizations (i.e., < 500 employees).  At least in this country SME’s represent over 97% of business organizations; they generate a significant share of the GDP; and they account for about half of new job creation. SME organizations also innovate, and their R&D spending usually accounts for a larger share of their revenue than for their large corporation counterparts. At the same time they lack the big IT budgets and internal expertise of their larger corporate counterparts.

This may seem like an ideal environment for adopting low cost information sharing and collaboration tools. The reality is that smaller organizations have tended to lag behind their larger counterparts in adopting Web 2.0 technologies. The reasons are hard to get a good handle on, partly because large organizations with big IT budgets tend to get most of the research attention. One recurring theme seems to be a lack of understanding at the senior management level about what Web 2.0 is, leading to skepticism about its value. On the surface, tools like Facebook, Twitter, Linked-In and Digg can easily look like a waste of time. And to be fair, it’s just as easy for people to waste time socializing on line as they used to do at the water cooler. However, important information exchanges and relationship building have always happened in “water cooler” conversations. Moreover, people in smaller organizations often depend heavily on a network of relationships that go outside the organization in order to expand the store of expertise available to them. When used judiciously (including some basic do’s and don’ts) social media can help.

It doesn’t stop there, because broadly defined, Web 2.0 tools include on-line tools targeted specifically for Team Collaboration and Project Management.  Examples include OneHub, EasyProjects, Entry.com and vPMI Express . They differ from each other in terms of specific functionality but they share in common the means to provide inexpensive access to capabilities that until recently were simply out of reach for smaller organizations. More details about each will follow in future posts. In the meantime please feel free to share your stories.

Comment

A Learning Approach to IT Projects

7 December 2009, 2:26 pm

In a recent series of posts on HBR,  Susan Cramm talked about the problem of getting IT leaders and business leaders to agree on how to approach system redesign projects. That led naturally enough to a  discussion about Big-Bang versus iterative approaches, and how the latter make some business leaders nervous. The paradox is that an iterative approach sounds open-ended and difficult to control, but a well thought-out iterative approach often delivers  value to the organization more quickly. That begs the question, what does a well thought-out iterative approach look like?

Most system implementation projects involve groups of people learning to work in new ways, so a better way to phrase it might be what does a ‘learning approach’ look like? Defined that way, visible success would be people using the new software tools to work in ways that are more efficient and effective than what they did before. Adults usually learn best when new things are set in a context that matters to them and then broken down into incremental steps that let them to pace forward in cycles that build on what they have learned. The implementation process should be structured the same way — give the people who will work with the system a context for understanding the changes and then equip them to learn in cycles.

In practice this means starting with a short term goal (say 8 – 12 months) that people can easily see as a foundation step toward the benefits that originally prompted the resign initiative. Was it finance, customer service, order management or something else? That goal should be big enough to deliver tangible value but it should not be too big either (that just sets people up to fail, and creates a bigger hole to dig out of than doing nothing). Renting some expert help early in the game helps to make sure that initial scope definition doesn’t lock in mistakes that could be expensive to fix later.

With a first stage implementation scope in hand, the people working to make it happen need the time and resources they need to do the job right. Also, senior managers need to reinforce the message about what is changing and why at every opportunity. That includes requiring the sponsor to stay visibly and intimately involved with the project team. Celebrating the success of achieving the first milestone helps everyone start to see a long process of change as something positive.

One outcome of first-stage success is that some of the internal team become experts who can support the rest of the redesign process. Dividing the change road-map into 4-6 month cycles will help the change process to keep pace with the rest of what is going on in the organization, and keep use of the system focused on things that actually matter to the business.

One of the outcomes of first-stage success is development of an internal team of experts who can support the rest of the redesign in a cyclic process that builds on what has been learned. Dividing the rest of the change road-map into 4-6 month cycles will help the change process to keep pace with the rest of what is going on in the organization, and keep use of the system focused on things that actually matter to the business.
1 Comment
« Older Entries