Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Is Wiki-based Collaboration the Answer?
Situation: Your collaboration tools just aren't cutting it. The range of SaaS tools out there has expanded way beyond BaseCamp knock-offs to tools that approach projects from a variety of angles. Each tool has its own heritage that’s reflective of what the vendor believes is important. One interesting tool that I’ve looked at recently is PBworks, formerly known as PBwiki. Their approach is very collaborative in nature and less structured than most. By providing easy ways for you to define your own structure, they hope to provide tools you can make fit your work style, versus having to adapt your work to rules imposed by the tool.We recently spoke with Chris Yeh of PBworks, who told us a bit about their approach to collaboration and managing knowledge. Here’s what he said. Q. You guys firmly believe that wikis provide a better collaboration platform than folder-based file sharing or email. Can you tell us a bit about why that is? (provide examples if possible) Wiki-based collaboration provides several major benefits that file sharing and email simply can’t. First, let’s deal with file sharing. The issue with file sharing is that it’s difficult to understand how a document has evolved over time. At best, you might be able to view different versions of the file from some archive. With a wiki, revision and change management are an integral part of how you work; all revisions are stored, you can see the history of changes with a single click, you can compare any two revisions, and you can always revert back to a prior version. This kind of flexibility gives people the freedom to be more creative; you can take more risks because the revision history is there as a safety net. Wikis also allow true co-authoring, rather than simply passing redlines back and forth. When a group of people works on a document, the asynchronous edits are notoriously difficult to re-integrate. Usually, whoever is responsible ends up having to read through several different drafts and manually integrate comments and suggestions. With a wiki page, everyone is always working on a current version that reflects everyone else’s edits. This decentralized approach saves a ton of time. One of our customers is Deloitte Digital, which uses us for creating new business plans. Their CEO, Peter Williams, reports that using PBworks lets them cut down the time they spent on editing final reports by 90%. With email, the issues are slightly different. The problem with email is that it’s so easy to lose the context of the conversation. Most emails are not self-contained; to understand them, you have to read the entire conversation to pull out the nuggets of information that are actually relevant. A wiki page provides a centralized, authoritative record; it is largely self-contained, and once you read it, you can make a decision or draw a conclusion. Another PBworks customer is Capgemini, the consulting firm. They were able to use PBworks to cut down project-related emails by 90% on one of their marketing projects. Q. You seem to specialize in certain industries, like creative, legal and financial services. Is there something special about the ways that people work and collaborate in those industries that make your approach a fit? We focus on use cases where individual users have to deal with multiple projects and initiatives, and where communications need to cross geographic or corporate boundaries. We’ve designed our product so that not only can you use hosted wiki pages to collaborate, you can also get a personalized dashboard of activity, tasks, and milestones across all of your different projects. For example, while designers and lawyers may seem very different, the challenges they face at work are very similar: They are staffed on multiple projects for multiple clients, and they have to keep track of a lot of tasks and information. Both lawyers and agencies end up using PBworks in a very similar way to manage their client projects: They create new workspaces for each new project or case (using our workspace templates), they collaborate with a project team to get things done, and they track their progress using a personalized dashboard. Whether you’re building informercial websites like Livemercial, or prosecuting a personal injury case like McConnell & Sneed, the collaboration process is very similar. Q. Every toolset has implementation challenges. What are yours and what approaches do you use to get around them? One of the big challenges with adopting a broad collaboration platform like PBworks is that there are so many possibilities. Even I don’t know all of the capabilities of the product, and with our engineering team adding new functionality all the time, sometimes people aren’t sure where to begin. That’s why we put such a heavy emphasis on certain specific solution-focused product editions, like Project Edition for project leaders or Legal Edition for lawyers. This allows us to do things like build usage-specific templates, instructional videos, and case studies. We also back up our product with some of the best service in the business. You can contact our support team via email, and get a response from a real human being in hours, sometimes even in minutes. And if you need help getting started, we offer a $100 custom trial package which gets you professional services to customize our product and provide a one-on-one training session. Q. A big part of project management is having a high-level view of what’s going on. There’s no gantt chart view, task dependencies, etc. in PBworks. Is that intentional or are those features to be added later? It’s intentional. We’re big fans of rapid iteration and innovation, so our general approach is to launch a simple, usable product, and build up from there based on feedback from real users. For example, PBworks started off as PBwiki, a bare-bones hosted wiki. It didn’t even offer user accounts. But over time, it’s evolved into a full hosted collaboration suite, complete with document management, basic project management, and even a mobile edition for iPhones and Blackberries. After we launched Project Edition, we immediately began hearing feedback on issues like task dependencies and measuring resource load. We’re working on such features, and many more. It’s also the case that we heard from a number of project managers who thought that the level of detail and customization was just right. Let’s face it; many projects are not complex enough to warrant a full project management solution, yet are more complicated than a simple to-do list can handle. PBworks is great for those ad hoc projects that make up most of our work lives. Q. What do you feel the biggest challenge in collaboration today (beyond what you’ve addressed in PBworks) and what is your organization doing to address it going forward? The biggest challenge in collaboration today is encouraging the end user to make online collaboration an integral part of their daily work. Tools that require users to abandon old but comfortable ways of working, or that require double entry, aren’t going to work out in the long run. I think that collaboration has a lot to learn from the bottom-up usability of social media tools like Twitter. These informal and unstructured tools are a great way to handle the initial phases of brainstorming, when you don’t even know the objective of your proto-project. We’re looking very closely at these tools and how our customers use them so that we can integrate their lessons into our products. Ultimately, collaboration is about bringing together, people, processes, and production. Collaboration vendors won’t be successful unless their products can bring together all three of those elements. |
Posted on: August 08, 2009 10:51 AM
| Permalink |
Comments (9)
Positive ROI from a Project Management Conference?
| Situation: You're on the hunt for great PM learning deals. The bright spots in this economy are coming in the form of great deals from leading providers. Two weeks ago, I told you about ESI’s awesome $500K scholarship program for unemployed PMs where they are giving away enough training to get hundreds of folks certified at zero cost. This week I’d like to call your attention to the MS Project Conference
Think of it this way. If you are planning to upgrade your MS Project software anyway, you might as well buy it here and improve your skills for free. However you think about it, it’s a great deal. In the interest of disclosure, Microsoft is one of our advertisers and we are sponsoring this conference. However, this is (of course) something I’d write about either way. |
Posted on: August 06, 2009 09:46 AM
| Permalink |
Comments (0)
What's Your Requirements Architecture Mean to You?
|
Situation: You want to understand how organizational influences impact your work. |
Posted on: August 01, 2009 10:51 PM
| Permalink |
Comments (4)
Free, High-Quality Training?
| Situation: You want to turn your jobless stretch into a huge gain. I'm always skeptical about training 'scholarships'. So when the folks at ESI brought their program to my attention, I was thinking "here we go again...". After closer examination however, I think this program is pretty cool - and very generous. Here are the basics of the program:
“Despite the current economy, project management as a profession is expected to grow substantially in the next few years with an increasing demand worldwide in such project-intensive industries as manufacturing, pharmaceutical, construction and IT,” said John Elsey, President & CEO, ESI. “This program will allow professionals to keep up their skills in the industry to take advantage of these leading economic opportunities.” There are a few questions we thought you would want answers to right away. John was kind enough to answer them below... Q. Are the candidates selected based on any criteria other than being unemployed? Or is it first come first served for people who are jobless? (if there are additional criteria, what’s the best way to get selected?) John: We wanted to help as many people as possible with ESI’s $500,000 Stand Out Scholarship; keeping the qualification and application process easy was vital in achieving that objective. So as long as someone is unemployed, can show proof of unemployment, and is a US citizen or permanent resident, they are qualified for the scholarship. Awards are issued on a first come, first served basis when the completed application and backup documentation (found at www.esi-intl.com/scholarship <http://www.esi-intl.com/scholarship> ) is emailed to [email protected] or faxed to (703) 558-2261. The only other consideration is that there is space available in the class they’ve selected; if a class is full we’ll work with them to try to find an alternative. Q. What are the most popular classes in the project management curriculum? In the business analysis curriculum? John: We offer more than 30 courses in our Project Management and Business Analysis. curricula, from entry level to advanced training. These are all eligible under the ESI SOS program. While our program’s core courses are generally the most popular, the relevancy of the course based on the individual’s experience and skill gap is the most important factor to consider when selecting an appropriate course or program. Many of our courses are offered in the public classroom, e-Training and instructor-led Virtual Classroom formats. Q. How many more courses beyond the three would someone have to take to get an Associates or Masters through the program? John: With just three courses total someone can earn an Associate’s Certificate in Project Management from ESI and our academic partner The George Washington University. Since people can apply for and take up to three courses with SOS funds, they have the opportunity to quickly and inexpensively earn an impressive certificate which they can add to their resume. Students can earn a Professional Certificate in Business Analysis with a total of just five classes. Or a Master’s Certificate in Project Management with a total of seven courses. Plus, GW will award advanced standing toward its Master of Science in Project Management to those who earn a GW/ESI project management Master’s Certificate and meet other requirements. Our Course Counselors are available to help students determine the best courses to achieve their learning and career objectives. |
Posted on: July 13, 2009 10:34 AM
| Permalink |
Comments (3)
How Agile Development Methods and ITPM Help With Cost Control
Situation: You are considering an Agile/Traditional mix of approaches..jpg) When you think of portfolio management, traditional approaches to project management seem to be a natural fit. However, Agile approaches, with their tight focus on business needs, are steadily increasing in popularity. In many cases, Agile is used within the core development team, but as part of a larger, phased delivery project. These “blended approach” organizations still have a need to practice sound project and program management disciplines, but allow the Agile teams to work in the manner associated with that approach. An ITPM solution is required to manage the total project portfolio, but must be flexible enough to address these different methodologies. In the end, IT must manage the end to end Agile development effort, from backlog to sprint delivery, all within the context of the broader Project Portfolio view. All of this seems difficult enough to manage on its own. So how can these varied solutions go one step further and help you control costs?We recently spoke with Rick Moreau, Director of Field Enablement, Compuware Changepoint Solutions, who has a great deal of practical experience in this area. Here’s what he had to say about how it all fits together. Q. Mechanically, dealing with efforts that are a mix of traditional and Agile approaches seems tricky. Can you give us a few “rules of the road” for making it work efficiently and effectively? Your introduction hits the nail on the head: Organizations need to be able to leverage an Agile development approach, but still need to make higher level decisions utilizing a portfolio management discipline. So the decisions about which projects to take on, which investments to make, etc. are still handled by the demand management and assessment functionality of the portfolio management process. Once the decision has been made to take on a particular project, some or all of that project may be managed using Agile. The key is that some boundaries have been set for the project as a whole, such as start and finish dates, total budget and perhaps even the minimum included scope. The Agile teams then take over to do the detailed planning of the sprints or iterations. Q. The Agile mindset is often described as beginning with the concept that “your initial plan is wrong”. Done incorrectly, that can make end results questionable or less predictable – which doesn’t help when you are prioritizing projects, managing resources, and cost. How do you manage that from a PPM perspective? I’m not sure I agree with the Agile mindset taking the position that “your initial plan is wrong.” The Agile mindset is more about deciding what can get done and in what order, rather than laying it all out in a detailed plan in advance. Agile teams will make a “best guess” at what they can complete and will then refine the requirements and associated estimates as development proceeds. I think that the PPM perspective and the Agile mindset can co-exist in an organization. As a matter of fact, they will have to co-exist or that organization will have tremendous difficulty delivering value to the organization. If we look at the basics of Agile we see a reasonable initial estimate of the size and make-up of the sprint teams, duration and number of sprints in the overall project plan. This gives us what we need for resource demand and capacity analysis. The identification of critical or high priority backlog items gives us what we need for “minimum scope.” So the PPM perspective has what it needs at the high-level for planning the resource utilization, schedule and cost. The Agile mindset can then take over the detailed planning at the sprint level, working within the boundaries of the dates, sprint team size and priority backlog items. They organize and prioritize using the Agile processes and add additional items if capacity is available. I see that as not much different than traditional project planning on a large project. Many projects cannot and do not have detailed project plans from the very start. They have high-level tasks identified for various work packages, with a best guess of resource needs and dates. As the project proceeds, these high-level tasks get defined to a more detailed level, usually 90 days out. Conceptually, that is the same thing we are talking about to support Agile within the larger discipline of PPM, except we may now only be talking 30 days out. Q. Do you feel that, generally speaking “more Agile” = “more business alignment”? What are the implications here from a cost perspective? The theory behind Agile definitely means more business alignment, no doubt about it. The product owner--i.e. the business representatives--identify the requirements and prioritize them. They have the right to change them anytime they want, expanding the requirements, changing priority of items, etc. The role of the Agile teams is to do the things the product owner says are most important. As long as the product owner is representing the business, and not just a resource within development, you can’t help but be more aligned with the business. But realize that the alignment with the business starts earlier than the Agile portions. The decisions to do a project or build a product or have another release should be made with business alignment at the forefront. Business alignment starts with the portfolio planning decisions. The Agile portion simply helps the development groups maximize that alignment and value by working very closely with the product owner. From a cost perspective, I think organizations have more visibility and control than they may originally think. People tend to think that Agile gives away all ability to have a budget and track costs. That’s simply not true. Backlog items have an estimated effort associated with them, sprints have a planned duration and team size. This provides us what we need to build a project budget and have an initial scope of what we will get for that investment. We can, in essence, build a budget for the sprint and track accordingly. What we give up is the ability to have a detailed cost estimate for every backlog item or requirement until we get started on that item. We will have the initial estimate based on the backlog estimate, but not the definitive estimate until the team starts working on it. I don’t see this as a huge sacrifice when you consider how many tasks or requirements on a traditional waterfall approach end up going through a change request process, or at least should. Q. I understand how Project Management can help reduce costs or enhance ROI, but how can a managed Agile/Traditional blend help you do that more effectively? I’m not sure a combined approach helps reduce costs, but I think it helps you increase value. What I mean by that is you may spend the same amount on the project, using the same number of people for the same length of time. But you will get the highest priority items delivered as part of the project and delivered in a way that meets the requirements of the business, since they will be able to refine those requirements through the Agile process. If all goes well, the Agile process will allow you to include even more things in the project than originally included, thereby increasing the value even more. In the worse case, the high priority items may turn out to be so complex that the project cannot meet the initial items within the desired timeframe. That may lead to a decision to stop the project altogether. That should become evident early in the Agile cycles, so the cost of proceeding with the initial sprint and then determining if that is acceptable is likely no different than the traditional spending on an initial “definition” phase. The key is to have the discipline to stop the project if it will not be delivering the required payback, whether that is determined in a traditional definition phase or in the first few sprints of an Agile process. Q. I’ve had conversations with analysts that describe your Agile integration approach as industry leading. Your leadership position in this month’s Gartner Magic Quadrant and the report narrative seem to support that as well. What specific or unique tool features enable effective Agile integration? (and Why?) What have you learned from implementations so far and what future changes are coming as a result? There are four areas of Changepoint functionality that have existed for several years and allowed us to incorporate support for Agile without having to build customizations to the core code. The first is request management, which is the ability to capture an “item” of any type, route it for initial review and place it into various statuses. This provides the functionality needed to capture and track product backlog requirements. It gives us the flexibility needed to support any different type of requirement and any preliminary review process a customer may desire leading up to placing the item in the backlog. The second area is our configurable workflow and the ability to define a logic step, which is the ability to have the workflow perform a complex action. We have leveraged this to take the items selected for the sprint and automatically create the sprint tasks and assignments on the project plan, so the team members do not have to. The third area is the ability to have distributed project managers within a Changepoint project. This allows you to have a defined user at a summary task level that can add and remove tasks just to that portion of the project plan. We refer to this as Summary Task Managers, but it was also perfect functionality to support the concept of the Scrum Master, who can add and remove tasks within a scrum or sprint. The final area is the Changepoint Report Designer. It provided the functionality we needed to build the various reports necessary for the Agile teams, such as the backlog reports, burn-up and burn-down and the sprint task board. Compuware Changepoint recently introduced an Agile Accelerator which is a pre-configured version of the Changepoint solution. The accelerator leverages the functionality mentioned to deliver best practices to support agile development processes and the associated reporting requirements, giving customers a starting point to manage agile development within a broader portfolio of projects. It is still early for much implementation experience, but one thing we are seeing is that all companies do things slightly different, even with Agile. We have seen this over the years with respect to standard project management processes and it also holds true with Agile. Fortunately for us and our customers, the flexibility of Changepoint allows them to easily make changes to the configuration, workflow and reports to meet their specific process. |
Posted on: July 04, 2009 06:54 PM
| Permalink |
Comments (1)