Project Management 2.0

New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog


Recent Posts

8 More Templates to Save You Time

What's The WORST Thing a PM Can Do?

9 Amazing PM Templates

Coded Messages > What Are "Project People" Really Saying?

11 BRAND NEW Templates to Save You Time and Improve Your Performance

Managing a Portfolio of Accidental PMs
Categories: Interviews

How do you steer a portfolio managed by a "mostly accidental" group of Project Managers?

PPM Software is becoming more "accidental-friendly" and Brightwork is a great example of that. Recently we spoke with Eamonn McGuiness, CEO of Brightwork to get his perspective on how to best manage those who consider PM a role they play rather than a profession. Here are his responses to our questions...


Dave:  Give me three words (not phrases) to describe Brightwork.

Eamonn:  Oh man, only three words… you’re breaking my heart!  But if I have to give just three, they would be:

Projects, Success, Easy. 

Hopefully you can see how those go together to create the BrightWork vision.


Dave:  What type of business and/or end-user is Brightwork MOST useful for? (e.g. - Small Business vs. Large, PM Mature/Not PM Mature, Line of Business Projects/IT Projects, Professional PM/PM as a role, Industry, Large/Complex One-offs vs. highly repeatable small projects)

Eamonn:  These classifications are very good, so let me talk a little bit about these in relation to BrightWork. 

  • 50% of our customers would be divisions within large enterprises who use our software for their project work.  The other half of our customers are small to medium-sized businesses, who use BrightWork extensively across their entire business.
  • The organizations that use BrightWork might have a few formally trained PMs who are leading the charge for project management, but they are not available to all projects. By and large, the majority of the folks are what we call P-MBAs – or “Project Managers by Accident.”  The idea behind our template driven approach to project management on SharePoint is to bridge that gulf in maturity and give project teams a fast and easy place to start, with the amount of project management that the entire team is ready and able for.
  • BrightWork can be deployed for use in any number of business areas.  Many of our customers do use it to manage IT projects, but we also have customers using BrightWork in other areas as well such as product development, professional services delivery, marketing projects, and more.
  • BrightWork is used by organizations across all industries.  If you check out the case studies on the BrightWork website, you will see that we have lots of customers across several different verticals. A neat thing about BrightWork is that it can be configured to match local or industry standard practices.
  • Finally, we have customers using the product to manage large complex projects, as well as more routine, repeatable projects.  When I explain our templates later, I’ll give an example of how this works in the product.

So to summarize the answer, the real strength of BrightWork is that we specialize in the mix of project management scenarios.


Dave:  How would you compare Brightwork to Microsoft's Standard Sharepoint offering?  How does it compare in terms of both collaboration and PPM/EPM functionality? In terms of price? 

Eamonn:  When you think of SharePoint you think collaboration.  It does just what the name says – it is a place to bring your team together to work, share and collaborate.  But for those organizations that want to go a step further using SharePoint to manage projects and across portfolios, they will note that there are boundaries to the out-of-the-box project management functionality. 

Microsoft has built SharePoint as a platform that is designed to be extended. So where SharePoint is collaboration, BrightWork adds project and portfolio management functionality, such as:

  1. Best practice templates to consistently initiate, plan, track and control all projects
  2. Portfolio management templates and dashboards for visibility across many project sites
  3. Status reporting, project metrics and KPIs for quick views into project health
  4. Template design sync to easily configure and replicate best practices
  5. Enhanced sync with Microsoft Project

SharePoint has a free version, called SharePoint Foundation and there is also a version that you can pay for called SharePoint Server.  Now SharePoint itself does not include PPM, but that functionality can be obtained through licensing a third party tool such as BrightWork on premise, or in the cloud paying per user per month. BrightWork pricing can be found on our website.


Dave:  Does the Brightwork Portfolio Management offering work best in a loosely structured or tightly structured environment?

Eamonn:  BrightWork is uniquely qualified to fit a mixed structure environment, so let me explain that. We have developed a really simple framework for project and portfolio management on SharePoint that allows organizations to start in where they are ready, and then add more process as needed, or use some combination of the two.

Here is a really simple spectrum we like to share.  Across the top of the diagram it goes from left to right, starting with a little bit of project management, to a lot on the right.  Then down left hand side, you see we have four workloads such as managing projects, managing portfolios, managing demand and managing work. Then we said well, you could manage projects with a little bit of project management or a lot, so we built templates for each.  You can manage portfolios with a little bit of project management or a lot, and we built templates for those too.  So all combinations of work and process are built into the product as SharePoint templates. 

It’s a very simple approach that we encourage our customers to use and adapt to their own situation.  For example, they might have several routine projects in a Project Lite template, a few complex projects using the Structured template, and then you manage across all those projects with a semi-structured Project Office.

Dave:  How do your best practices templates work? Are they based on proven methods and how does one decide if a particular template might work for them?

Eamonn:  The idea behind the templates is that they allow you put in whatever project management practices you desire and give that to the project team as a starting point.  You give the people a SharePoint site that is a set of rail tracks to guide project managers and teams.  It is a very pragmatic approach to getting started.

The SharePoint templates are based on project management best practices, and are intended to give organizations a fast starting point to manage their project work.   The templates enable teams to get started quickly with the amount of process that is necessary for the project at hand.  The choice of which template to start with is governed by two main factors.  One is the amount of project management that the project needs to be successful and secondly, the amount of project management that the team is capable of absorbing.  The templates are also designed to help you to evolve your project management maturity to where you want it to be.


Dave:  What percentage of your portal customers customize the application to integrate with their internal systems?  What are the drivers behind that decision?

Eamonn:  This would not be the primary concern for the majority of our customers. Most of them are more concerned with getting project management up and running really well, as opposed to integrating with financial, budgeting or other internal systems right off the bat.  That type of integration would typically occur in a later iteration.


Dave:  You talk about having a structured approach to implementation and rollout.  In your mind, what are the three most important factors when rolling out any sort of Project or Portfolio Management toolset?

Eamonn:  I think you might expect me to call out factors like: a commitment to project management, the aptitude of project management resources and the availability of training.  And those are three factors that are very important to the process.

But at BrightWork we like to use a quote from the ancient Greek philosopher Aristotle, and that is: “That which we learn to do, we learn by doing.” So the best way to get good at project management, is to practice project management.  With that in mind, here is our approach:

1.      Start quick – with the amount of project management your team needs and is able for, and get some quick wins. 

2.      Stay relevant – decide the amount of project management you aspire to achieve, and then gradually build up to it bit by bit as needed.

3.      Evolve at pace – make the deployment process a series of projects itself, in which you deliver an amount of project management quickly, get feedback from the team, and build that into the next iteration.

Posted on: March 02, 2014 12:02 PM | Permalink | Comments (0)

Risk Management: A Process or a Way of Life?
Categories: Interviews, Risk

Situation: You organization needs to take risk management a lot more seriously.

We recently spoke with Loren Padelford, Executive Vice President & General Manager at Active Risk. The folks at Active Risk talk a lot about establishing an "Active Risk Culture" at your organization - really making risk management a way of life, rather than a set of sterile processes. As a concept that sounds interesting, but how does it really work? Loren offers some clarification in his responses below.


How much difference can having a "Risk-Aware Culture" have on a business? Can you compare it to simply having Risk Management processes in place or even just using general policies to manage risk?

The difference between risk awareness and simple risk management is immense. In a risk-aware culture, risk is part of everyone’s daily activity. Most firms would argue that they have a risk management “process” or “policy” in place, but a risk-aware culture means that risk is analyzed to a granular level - where it has the most impact. This means that every single person within an organization, from the CEO to the finance department to the newest project manager, not only understands their risks, but implements and uses risk management on a daily basis. If everyone understands that their role has a component of risk management involved and that risk management needs to be practiced every day, than the organization’s ability to understand its risk at a more in-depth, mature level, increases.

We’re seeing and research is showing that organizations with higher levels of risk maturity have improved in profitability, enterprise value, and opportunity generation.”


Q.  Could you describe how a Risk Aware Culture is established?  What are the top 3 (must do) components of the process?

Establishing a risk-aware culture can be a relatively simple process if the organization, on an individual level and as a whole, is committed. Having executive level support is number one. Having the CEO involved in the process and actively understanding his or her own role as a risk manager is a must. Without senior level support and daily involvement, risk is seen as optional and a risk-aware culture will not be achieved.

Secondly, an effective risk management process must be goal-focused. In order to draw employees into the process, each individual in an organization needs to establish tangible goals that they want to achieve through risk management. Risk needs to be a valuable process to the people who do it every day and setting goals will show them how effective risk management is in helping them achieve their goals more quickly.

Finally, organizations must be careful not to over-complicate its risk management. In order for risk to take hold in a culture and become engrained in everyday activity, it must consist of simple tools and remain focused on the risk that really matters to each individual’s goals and objectives.


Q.  How "Risk Mature" does your organization have to be to establish this sort of culture?  Are there pre-requisites to keep in mind?

Because risk is an ongoing process, there is absolutely no threshold for risk maturity. Organizations that want to become more risk mature simply need to focus on the three attributes mentioned above – executive support, setting goals and keeping the process simple. If an organization achieves these things, they will find themselves in a position where the company starts to pull in risk awareness naturally, instead of finding it pushed onto them.


Q.  When is it inappropriate to establish this sort of culture? In which industries is it more difficult?

Because every industry encounters risk on a daily basis, it is never inappropriate to establish a risk culture.

Additionally, every industry has a certain requirement to take risks in order to create opportunity. Of course, all industries have their particular challenges and some are more complicated than others, but there is never a time and place when risk is an inappropriate process to engage as a core component of a company’s strategy.


Q.  Given your company's deep experience in fostering effective Risk Aware cultures, could you tell us what this takes from a staffing and a tool perspective?

From a staffing perspective, the organization must have executive-level support. I cannot stress this point enough: the Chief Executive Officer must also serve as the Chief Risk Officer. They will be the educator of risk throughout the organization and translators of the goals and objectives of the business. They are not only imperative to the success of the process, but they are the cultural enablers bringing risk to an organization-wide level.

Without the right tools, it’s nearly impossible to execute risk management well. Organizations should look for tools, like Active Risk’s ARM solution, that provide a centralized hub for all risk information, so that the defined Chief Risk Officer is able to own the risk management process. This tool should integrate seamlessly into existing systems and processes, and have the ability to be personalized to each user’s needs.

The most successful organizations are the ones who have taken the approach of giving individuals high power and highly capable, yet simple to use tools to support risk management as a daily activity in business. These are the organizations that reap the rewards of a risk-aware culture.


About Loren Padelford

Loren is responsible for all customer-facing activities at Active Risk including sales, marketing, services, partners and customer success.

Loren has a broad track record of success in technology, advertising and business services. Prior to joining Active Risk, Loren was Vice President of Strategic Alliances and Global Sales Director for Dyadem International, a leading enterprise HSE software provider. Loren was a key member of the leadership team and instrumental in the growth of the business, which led to the acquisition of Dyadem by IHS (NYSE:IHS) in April of 2011. Prior to Dyadem, Loren was National Sales Manager at Recall Corp, Sr. Director of Sales & Account Management at advertising firm Uthink and started his career selling photocopiers with Ricoh Corp.

Loren holds an MBA in Marketing from the University of Liverpool Management School, a Bachelors of Psychology from the University of Guelph and is a Certified Sales Professional.


Posted on: November 30, 2012 10:27 AM | Permalink | Comments (0)

Another Supportive Community
Categories: Collaboration Tools, Interviews, PPM Software, Web-based Tools

Situation: You are a user of Daptiv's products and need a little help from time to time.

Daptiv is launching a new online community to promote social interaction between its customers and employees. It allows you to share FAQs and new product ideas, and serves as a one-stop knowledge base and training resource.  With more than 100,000 Daptiv subscribers, this community should be fairly significant right away. It will be interesting to see what impact it has on Daptiv users and the businesses they support. We recently spent some time with Ian Knox, Vice President of Products and Marketing, from Daptiv to find out more.


Q. Tell us a little bit about this new community you are starting.  What are it's goals and what do you see as the immediate benefits to your user base? What will be the benefits for Power Users who are consistently active on the site?

The Daptiv community was conceptualized with the aim to foster product innovation and streamline the whole process of knowledge sharing through mutual collaboration. This new platform gives all its users an opportunity to collaborate directly with Daptiv peers and employees to receive timely responses to product related queries and leverage the community’s knowledge of best practices.

A highly user friendly and intuitive platform, it makes it easy for all the users to access the training courses and refer to knowledge based posts to advance expertise in Daptiv PPM whenever in need. The Greenhouse’ feature of the platform allows customers to share ideas and vote on new and innovative features for Daptiv’s product roadmap. It’s like an interactive knowledge house which is just a click away from its users. Active users and contributors will be abreast with the latest in technology, product and capabilities.


Q. How is this similar to or different from the MS Project 2010 Community or MPUG?

The Daptiv community includes a couple of unique capabilities. First, the platform is an evolved version of our Greenhouse community that was launched back in 2008 and enables customers to propose ideas and collaborate with our product team. Second, we include a library of Daptiv PPM applications and reports, which enable users to download best practice components and use them immediately in Daptiv PPM. This is addition to our blogs, videos, forums and knowledge base.


Q. Will Daptiv employee participants be pre-selected, or any anyone at the company participate?

Just like a community, this new platform is open to all of Daptiv’s users and customers. It’s an open development platform and a community of contributors. The community not only encourages exchange of knowledge, but also allows Daptiv to stay in closer contact with clients and partners.  


Q. Do you see Daptiv partners playing a role in this?

Absolutely! Daptiv partners are an integral part of this community. Our partners tailor to an array of sectors and we value the know-how that they bring in. This is a collaborative community where ideas, experiences and best practices are exchanged for better results. We are eager to listen in and drive Daptiv’s innovation process by creating a closer, more intimate dialogue with our customers.


Q. How do you see members of the community working together? 

We have designed the Daptiv Community to become the ultimate go-to resource to help customers with their PPM questions and deliver value for their businesses. We see this platform as a breeding ground for new ideas, seamless engagement and reliability.


Q. In terms of long-term vision, what do you see this evolving into over the next few years? Do you see the scope of this extending beyond Daptiv-specific best practices to more general PPM advice?

The basic premise of this community is to evolve constantly by adapting to the changing environment. Conversations are made in real world environment through open dialogue via discussion forums and an updated knowledge base.

Over the years, this community aims to serve as a one-stop entry point where both customers and employees pitch new ideas and initiate discussions with like-minded peers. Our vision is that this is the first place PPM practitioners from our user community come to ask questions, share best practices and connect with peers.

Posted on: November 09, 2012 03:11 PM | Permalink | Comments (0)

Agile Today: An Interview with Jim Highsmith
Categories: Advice, Interviews, Management Approaches

Recently, we spent some time with Jim Highsmith, an Executive Consultant at Thoughtworks and one of the fathers of Agile - and asked him a few questions about the state of Agile today.  We also talked a bit about how he sees the movement evolving going forward. He gave us some very interesting tips and best practices that all of our members should be aware of. This is definitely a “must-read”. Jim will also be conducting a webinar on Aug 22, 2012, 8am PDT, Dispelling Myths About Scaling Agile Projects. If you are available, the webinar will be a great opportunity to interact wth JIm more directly and ask specific questions about your specific Agile challenges. 


Q. Let’s start off with an update on you.  We all know about your involvement with the Agile Manifesto a decade ago.  Could you bring us up to speed on how you feel Agile has evolved and your current focus within the space?

There are three areas that I think have evolved over the last 10 years or are evolving now.

1. A move from Project Team to Organizations. The first is a change in who drives these efforts from project teams to organizations. During the first 4-5 years things were project team oriented.  Someone within an organization, usually with permission, would conduct a Agile “rogue project” really on a team-by-team basis. In the last 4-5 five years you have, CIOs, CTOs, Directors of Product Development, VPs of Engineering – those kinds of people –saying “we want to transform major parts of our organization” and making [Agile] more of a combination of bottom up and top down. All of this with much larger organizations getting into Agile over the last five years.

2. A move from engineering and team practices to management practices. In parallel, we’re seeing a move from engineering, engineering practices and team practices to something that is more focused on management and management practices. This is something that is really just getting underway in the last few years, where management and executives have taken a look at this and said, “What do we need to do to make our organizations more Agile?” (as opposed to just making our software engineering practices more Agile)  This sort of change from an engineering to a management focus is further demonstrated by the Project Management Institute getting into Agile and Agile certification; not everyone in the Agile community is happy with this, but at least it shows that there is a lot of interest within the project management community as well as within the technical community.

3. A move from Agile development to continuous innovation.The last thing that I would talk about is Agile Development moving from strictly development to continuous delivery and deployment. So your software, in addition to being developed on a short cycle, is being released on a very short cycle in those situations where it makes the most sense. So you have a situation where you are automating that last mile. On the front end of that, the exploratory or discovery phase, the lean startup movement has provided some practices and philosophy around getting starting faster with product inception and product requirements. Agile development to continuous innovation.

I’ve been focused on the management side of these changes, which I call adaptive leadership: 

  • Why is it more important for managers and leaders in organizations to be more Agile or adaptive?
  • What do these managers and executives need to do differently? What are the actions that they need to take?
  • What are the behaviors that we need to exhibit as Agile managers?


Q.  Could you expand a bit on what it means to be Agile?

In fact, I just wrote a blog posting yesterday entitled “What is Agility?”.  To me there are two aspects of Agility:

1. The ability to create or respond to change in order to profit in a turbulent business environment.  So it’s not just responding to change, but the ability to create change in innovative ways to challenge competitors.

2. The ability to balance flexibility and stability.  A lot of people think that agility promotes sort of a lack of structure. But really, if you don't have any structure at all you just kind of go off into chaos. So you really do need structure. The really critical management capability here is to decide how much structure you need and balancing that with the flexibility that you need to respond to the marketplace.  Traditional approaches have come down on the side of more structure, more process and more standards, and have really restricted our ability to innovate because we don't have that flexibility, adaptability and learning ability that we need to be competitive.


Q.  When trying to understand the limits of Agile practices, most people focus on project size. Yet you talk more about complexity and uncertainty, which are related but not as easy to get your head around. Generally speaking, what is the best way for practitioners to think about these two attributes of programs and projects and how each of them should affect their approach? Any thoughts on this specific to planning?

I think that there’s sort of a myth in the community around project size.  Part of this comes from the early Agile work that focused more on small teams and small projects. So the idea was that Agile worked well on small projects, but didn’t scale well to larger projects – but there are plenty of examples now of Agile working well in very large projects and large organizations.

You should really think about this is terms of a few key questions that Agile helps answer:

  • At what size does delivering value to customers fail to be important? (there is no such size)
  • At what size does the core value of creating better workplaces fail to be important? (there is no such size)
  • Can large organizations afford to be inflexible rigid and unresponsive? (of course they can’t)

So there are a lot of reasons that we want to be able to apply Agile as we scale.  So we want to scale Agile, but what are some of the things that we need to do to make that happen? That’s where complexity and uncertainty come into play.  Complexity and uncertainty are two dimensions that we need to think about.  The complexity dimension is the one that we are most familiar with; team size, distribution, domain knowledge, computational complexity all play into overall complexity.  Common uncertainty factors can include the newness of the technology you are using, business and marketing uncertainty, new/emerging product requirements. You can have any combination of high and low complexity and uncertainty on any given project, but the general strategy for scaling projects are as follows:

  • Increased complexity calls for increased structure: organizationally, from a communications perspective, documentation and use of tools.
  • Increased uncertainty calls for the incorporation of practices that make you more agile: increasing learning, shortening feedback cycles and increasing experimentation.

Obviously, the more difficult projects are the ones that have high complexity and high uncertainty.  With those kinds of projects you usually have a smaller subset with high uncertainty that you can deal with separately. I think the real message here is that you have to adapt and use some more traditional strategies and some Agile strategies as appropriate. Often you end up using an Agile strategy overall and incorporate traditional elements into it as needed.


Q.  A key challenge for organizations that we often hear about is marrying Agile projects with more traditional Project Portfolio Management efforts. The clear goal is to gain the benefits of Agile approaches while attempting to maximize and manage return on investment.  Do you have any thoughts, guidance or best practices that you could share in this area?

I think in terms of exploration (certainty) factors with my projects along two dimensions: technology and requirements. If the technology is very familiar to me, the technology exploration factor is low.  If the technology is new, the exploration factor is high.   The same is true for the project’s requirements. If I have an exploration factor 10 project, things are pretty uncertain.  If I’m dealing with a factor of 1, things are pretty certain. Most PPM approaches standardize/homogenize projects, making them seem equally predictable – which doesn't make any sense. For example, to expect predictability within +/-10% of time or cost on a exploration factor 10 project just isn’t reasonable.

So we need to change governance structures and govern different types of projects based on different criteria. With projects that have a low exploration factor, we can use more traditional portfolio measures like scope, schedule and cost. With higher exploration factor projects, we have to ask:

  • What’s the value the project will generate?
  • What’s the minimum viable product?
  • What can I release out the door as soon as possible in order to get constructive feedback? 

Then the other things like cost and scope become constraints – not drivers. So you have to either run two different types of portfolio management systems or one governance process that combines both traditional systems and Agile. One of the things that I’ve seen lately is continuous monitoring and management of the portfolio, using sort of a Kanban approach. It’s very similar to a traditional approach in some ways, but all of the actions are continuous.


Q.  Uncertainty is something that every company is dealing with today. It’s a key concern for every executive.  Moving Agile up the food chain, are there steps that can be taken to make a traditional PPM process more adaptive and perhaps more effective that are usually well received by the executive team?  Are there ways of coaching executives to make them more Agile-friendly and ultimately more effective in a world that is filled with uncertainty?

The transition is more a management transition than it is a project or portfolio management transition.  There is more of a realization now that managers themselves need to learn to be more adaptive. In the past, we’ve seen the attitude that the development teams need to be more Agile and adaptive, but managers thought, “It doesn't really impact me.” I think people are struggling with changes in the marketplace.  For example, Amazon fought for years against applying state taxes to Internet sales.  Now they’ve changed strategies entirely because they are moving toward same-day delivery. That’s an industry-wide disruption and an example of management thinking in a more Agile way. So that’s how the mindset changes.

The “doing” side of it really involves creating a continuous stream of value:

  • Being able to speedily deliver value.
  • Doing less, figuring out minimum viable products that deliver value.
  • Doing those at very high quality so you can do it continuously. It’s not about doing release 1 and 2, but doing release 1, 2, 3, 4, 5, 6 in very rapid succession.
  • Having a well-tuned engine to make all of this happen in a rapid, high-quality way.

The “being” side of that (management behaviors) has to do with creating an innovative culture:

  • Thinking about continuous change and adaptability as the norm.
  • How do I get my mind around having an “adaptive mindset”?
  • How do I measure progress differently?
  • How do I look at change as an opportunity versus as a problem?
  • How do I adapt an “envision-explore” mindset versus a “plan-do” mindset?

With a plan-do mindset, I plan out everything that I want to do – then I do it.  With an envision-explore mindset, I envision where I want to go and how I might get there.  With envision-explore, I'm creating an innovative culture.  With plan-do, you’re really not.

So in terms of dealing with uncertainty, the things that I just talked about help you deliver a continuous stream of value, while creating an innovative culture.


Q. Following the theme of uncertainty, what are your thoughts on planning in an uncertain environment? 

I think planning is definitely something you do, but really you’re “speculating”. In my book, I actually replace the word “planning” with “speculating”, because that’s what you’re really doing in a highly uncertain environment.

When a lot of people think about planning, they think about a Microsoft Project plan with 6,000 tasks and someone is going through and checking them off as they are completed. I think that kind of plan isn’t really appropriate in a rapidly changing environment.

What is appropriate is a higher level of planning where you are dealing with shorter periods of time and you’re dealing with larger chunks of work.  Again, you would plan an exploration factor 10 project differently than you would plan an exploration factor 5 project. If it’s a 10, you might just run an iteration at a time with a broad goal in mind and a few constraints – then run a series of experimentations on it until you figure out what it's all about.  With a 5, you might be able to lay out a reasonably detailed plan for three or six months.

Another key difference between traditional an Agile planning is what you are actually tracking. Traditional planning tends to be task or activity based.  In Agile planning, you are doing a product breakdown. So you’re tracking pieces of the product that have value to the customer versus activities where their value is less clear.


Q.  Organizational effectiveness has also been a popular theme in recent years. At various levels you see Agile, Lean and even Six Sigma playing roles in helping organizations produce more with less. Do you see these disciplines becoming more integrated or even somewhat merging at some point in the future? How do you see them complementing or detracting from one another?

The ones that I see complementing each other are more the Agile and Lean – particularly the Lean startup movement. The idea of doing less and focusing on high-value stuff is really a complement to Agile.

I haven’t had as much experience with Six Sigma, but it’s more about operational efficiency. There may be places where you want to be more operationally efficient. Then it’s a matter of creating a balance.

Organizations have to think about:

  • Do I really want to be focused on being more responsive? This is the driver that Agile and Lean help with.
  • Do I want to drive down costs (become more efficient)? This is a constraint that Six Sigma helps with.


Q. Organizational effectiveness often means standardization. Many large organizations struggle to "standardize" their teams.  What are your thoughts on this type of standardization? 

I think it depends on whether your focal point is responsiveness or efficiency. If your focus is on becoming more efficient, then standardization probably helps with that.  Unfortunately, that drive toward standardization often operates against the ability to be more adaptable, flexible or responsive. The more standard you get, the less flexibility you have. In many large organizations, this drive to be standard encompasses too many things.  There may be some areas where standardization is appropriate, but “teams” is not one of them. You need diversity and a set of guidelines, but not much in terms of standardization.


Q. Customer value is obviously critical, but maximizing it sometimes feels in conflict with getting things done. If you had one piece of advice for those trying to maximize value in a tough environment, what would that be?

I would go back to two of the four things that I think adaptive leaders need to do:

  • Deliver value to the customer
  • Do less to deliver that value

One of the things traditional approaches assume is that you’re successful if you’ve delivered all of the scope in whatever you’ve defined. There have been studies that say that 60% of all software developed is rarely or never used. So the measure really needs to be, “Have I delivered value to the customer today?” not “Have I delivered everything in scope?” Then you might ask the question, “What offers value now?” Then you can grow that value over time.

So the Lean idea of doing more with less, combined with an Agile approach, really produces more meaningful results. 

Posted on: August 15, 2012 11:15 AM | Permalink | Comments (3)

Have You Outgrown Basecamp?
Categories: Advice, Interviews, PM Software, PPM Software

Situation: You need a few more features in your PM software.

Project Management SoftwareWe recently spoke with Cynthia West, VP at ProjectInsight about one of the most common migration patterns we're seeing at the moment - a move from super-simple "to-do list" software to more capable packages. If you're a Basecamp user, there's a pretty big chance you'll eventually find your needs outgrowing the software bit by bit.  If you are in that situation now, read on and see if your experience matches up with what's typical in the industry.

Q. Basecamp is a terrific, inexpensive starting point for many. However, at some point most organizations grow out of it. Can you talk a bit about the triggers that prompt users to start looking at more capable products?

Yes. We think of the market for portfolio and project management solutions as having three basic tiers: the low end tools, mid-market solutions and high end systems. Basecamp is a great low end tool that offers collaboration and task management in a web-based application. High end systems are those designed for very mature project teams. They are more involved in terms of implementation timeline, more expensive and, in general, designed for more ‘top-down’ organizational cultures. Microsoft Project Server is a good example of such a system. Mid-market project solutions are more robust than the low end, but not as overwhelming as the high end systems. Project Insight is one example of project software that is robust enough for experienced project managers, yet easy for team members to adopt.

We talk to a lot of people that have started to manage tasks and collaborate in Basecamp. They like the alerts and the ability to see the tasks they are to work on. However, as you say, many project teams outgrow this tool. The initial trigger points that prompt teams to look at mid-market portfolio and project management solutions include the need for:

-Intelligent scheduling

-Gantt charts

What do I mean by intelligent scheduling? This is the need for something more than a simple task manager. As teams hire more professional project managers, they find they need the ability to link tasks together using dependencies. While some low end tools have the notion, not even all mid-market solutions have the MSP-like dependencies and constraints that more experienced project managers are familiar with.

In many cases, the more experienced project manager has utilized MS Project desktop and wants task dependencies, constraints and splits. At the same time, the organizations we help talk about having project managers of mixed experience levels, so they also want the newer project managers to be able to create projects from templates.

Gantt charts, of course, provide a visual view of one’s project and task flow. As projects get more complex, there’s nothing like being able to see the tasks on the critical path. Basecamp and other low end tools do not concern themselves with something as esoteric as a critical path or a baseline.


Q. There are always the problems you see and opportunities that you don't.  Can you talk a bit about capabilities that most of these organizations could use that they are not looking for right away? What sort of quantifiable impact could these functions have?

Sure. When teams finally get their hands on a product that performs intelligent scheduling and they have set up some project templates, they often feel that sense of relief. So, what’s next? At this point, they can benefit from resource allocation views and portfolio reports. If you are only looking at a bunch of tasks that are unrelated, it makes it impossible to shift schedules easily. It also makes it challenging to truly understand what people are working on and when.

Demand management, capacity planning, resource allocation…no matter what you call it, as project teams become more successful, they need a way to see what everyone is working on and when. Because growing organizations are successful, they often have the business challenge of not knowing if and when they can deliver a project on time. Proper resource views in mid-market resource management solutions are needed when organizations hit these levels of success.

As for the quantifiable measurements of the benefits of resource balancing and proper allocation, that is probably the ‘holy grail’ most PPM vendors are looking for. If it were easy to find an ROI measurement that every organization could utilize, then our lives would be much, much simpler. As far as I know, no vendor can offer up a simple ROI calculator that is applicable to most organizations.

That said, I can offer you some anecdotes from customers that lead us toward impacts. For example, one organization had a team of high powered software developers that he was losing. They were leaving for ‘greener pastures’ because the organization was constantly working late on their client deliverables. They would have a 600 pound gorilla customer call in and then everyone would work a fire drill. All of this due to not being able to see the planned work and allocate it properly.

Once they implemented Project Insight, they began to plan every team members’ work two weeks ahead. Once that was mastered, they began looking out a quarter and forecasting. The customer found that his attrition rate of his specialized resources was lower. Why? Because people could plan their lives. They went from working 80 hours per week to 40-50 hours per week. The employees were happier and remained with the company.

Last, but certainly not least, executives want a simple way to oversee all the projects in their portfolio. Low end tools do not always concern themselves with the needs of project managers or executives. Basecamp and others are more focused on team member needs, sacrificing other levels of the team.

Now this functional set is probably easier to quantify. We often hear of project managers spending a certain number of hours aggregating information for executive reports, and then someone else spend another set of hours formatting these reports. That is more easily quantified and can often, in itself, bring in the ROI for a mid-market solution.


Q. Are there staffing considerations when making this sort of (upgrade from Basecamp) move?  Should you not take it on unless you have a specific set of skills and competencies in house?

Yes, that’s probably true. If an organization does not have anyone that understands task dependencies, or is willing to learn about the power of intelligent scheduling, then it is probably not wise to upgrade as of yet. It seems that Basecamp appeals to organizations that are small and work with a lot of sub-contractors or freelancers, for example, tiny ad agencies that extend their workforce with subs. In these cases, it is probably overkill for them to worry about anything in the mid-market.


Q. At the other end of the spectrum from Basecamp, there are very high-end complex tools to manage project portfolios.  These are often six figure investments.  At what point do you need to start looking at these?

There are many organizations that are ready for a high end system. They have certain characteristics to be sure. For example, I attended a PMI chapter even with a Microsoft Project Server consultant as the guest speaker. He was firm and clear when he said, “Don’t even try to implement this unless your organization has a CMM ranking of 3.5 or better.” I would say that is probably good advice for any organization. Do not embark upon a high end system until you are mature enough to benefit from that system.

In May, at the Gartner conference, it was said that a solution like Clarity takes at least six months to configure, so you need to be at the stage where your team can dedicate the resources to analyze the business processes and spend that time configuring the system.

A couple of good examples of companies that use high end systems are Proctor & Gamble and Boeing. P&G has literally 1000s of products and tens of thousands of opportunities for improving these products, or launching new products. They have an entire department that analyzes the risk of each potential program and project. These opportunities are mapped onto a bubble chart and the like. The team has the resources to review the project/idea intake process, and analyze, and quantify well in advance. Many of our customers do not have the luxury of an entire risk management department.

Thank goodness Boeing and other airline manufacturers have mature processes, as our lives depend on it. The type of business requires stringent adherence to standards and processes in order to develop and manufacture their products.


Q. Project Insight has an established migration path from Basecamp.  Can you talk a bit about the data that is migrated over, how it's used, and where the gaps are?

Yes, as we upgrade lots of teams from Basecamp, we’ve developed a data migration for these customers so they can have their historical information available to them. We map the following fields:

Project Management Software

The gaps are the features that Basecamp does not offer like dependencies. So, if the project is in progress, and migrated into Project Insight, then the project manager needs to relate those tasks or just adjust each task manually. We did not migrate files, but one may simply use multiple file upload to pull the files into Project Insight. Everything else is good to go. 

Posted on: July 26, 2012 05:11 PM | Permalink | Comments (0)

"The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out, the conservative adopts them."

- Mark Twain