Archive for July, 2015

Agile and Conventional Projects in the same Organization?

Posted on: July 20th, 2015 by admin No Comments

I recently had a brief twitter discussion with Mario Lucero that lead to a lengthy discussion over Skype who lives in Chile (the world is not so large).  His recent experience suggested to him that a company that employed conventional project management to not be a good candidate for agile.  My experience ran contrary to that, I have seen some companies employ both methods, picking the approach to match the project scope and risks.  This made us wonder about the attributes that may predict success when it comes to introducing agile to a company.  He has put his thoughts into a LinkedIn post at




Command and Control in Agile and Conventional Projects

We discussed the philosophy of the company in which he saw the resistance to moving to an agile approach to the work.  From his perspective the company had an existing hierarchy and reassigning this hierarchy was not possible according to the company.  This approach made scrum masters and an agile team difficult to create.  The company was command control-centric and that precluded moving to a team based way of working.  There were issues on how to use the existing structure to make agile work?  Perhaps the existing structure would need to be reworked.  This is not just a structural issue, it is philosophical and to change this requires executive acceptance.

The Myth of Multitasking

Another impediment to being able to transition to agile was the belief that the product owner can carry multiple roles in the company.  The product owner carries significant responsibility in the product development. Product owners who are seldom available to answer questions about the product put the team in the same position as conventional project management perhaps even worse.  In conventional project management, the team has, perhaps, a significant measure of documentation from which to work.  This happens in any organization that believes in they myth of multitasking.

Both can happen though…..

It is possible for a company to embrace both the conventional approach to project management AND the agile approach, and even mash these two together to make the best solution for the organization.  However, this will require relinquishing some command and control structure, at least within these agile projects, as well as reduction or elimination of multitasking.  The ability for members of the project team to focus is one of the success factors for agile.

If you want to discuss this fascinating topic with Mario he can be reached on twitter (@metlucero), Skype (metlucero) or by gmail (



Project Management Tools and Risk Management

Posted on: July 16th, 2015 by admin No Comments

Project Management Tools and Risk Management

There still remains meat on the bones of this study from Software Advice.  On LinkedIn, Joe Hessmiller had an observation that Client relationship and Risk management was far down on the list of concerns. Under the heading More Buyers Request Advanced Functionality Than Basic[1] client management and risk management was at the bottom of the list at where 5 percent of buyers request functionality around risk management.  His interpretation was that “more interested in the accounting value than the project success value of PM tools”.  The list is as follows:

  1. Reporting and analytic
  2. Project planning
  3. Time & expense tracking
  4. Scheduling / calendaring
  5. Resource management
  6. Collaboration / Communication
  7. Budgeting
  8. Client management
  9. Risk management

Perhaps these buyers are not interested in risk management, because the risks to which they are presently subjected are on the list. For example, poor reporting and analytic or project schedule and calendaring routinely show up in their risks that come to fruition. In fact, my experience suggests the top six areas on the list are consistent sources of project malady if not down right failures.  Better or improved validity of information on these respective areas will reduce the risks commonly associated. For example, consider resource management.  I am sure many project management practitioners have probably experienced the complications and failures that happen with insufficient resource planning.  You believe the resource is secured, and then find out it is not and if there is a back up plan, that is risky at best.

At Value Transformation we have developed a Risk assessment tool that follows the  Advanced Product Quality Planning (APQP) Failure Mode Effects Analysis structure (FMEA). Instead of the Design or Process failure modes, we consider the failures from the project perspective. Check it out at

Project Management Tools and Transparency

Posted on: July 15th, 2015 by admin No Comments

Project Management Tools and Transparency

We continue with our review of the latest report from Software Advice.  Specifically, we will focus on one of the top three reasons or drivers for buyers are looking to move from manual tools to a less labor intensive project management tool.  The specific language is below:

The top reasons driving buyers to consider Project Management solutions for the first time include the need to[1]:

  • Improve organization (54 percent);
  • Automate processes, such as task management and time tracking (48 percent); and,
  • Increase transparency of project statuses and updates (45 percent).

I have some bad news for those purchasing project management software tools to help them to transition to transparency.  I can understand how one of the goals should be to see things how they are and not how things are spun or articulated ambiguously to intentionally mislead.  This attribute of an organization is a function of the organization and not driven by a tool, though a tool perhaps can help.  The problem is the tool is a way to record, and involves human interaction. Therefore, a tool will not entirely solve this issue of truthfulness in reporting on the project status.  In fact, without a cultural change this tool may only present a new obstacle for how to massage the data to reflect what is wanted to see, but not what is actually there.

If you want a transparent organization, I think you have to start at the top. You must recognize that everybody must model the behavior that is expected.  The organization must not shoot those that prefer to work transparent, and work them over for not doctoring the data.  You do not change corporate culture and level of transparency by rewarding those that least exhibit the behavior.  Those that show fake numbers or otherwise misrepresent the project situation and are immediately promoted upon project closure. Only we find in the next ensuing months we have massive quality problems that we must fix in the field – costing our company dearly.

It is incoherent, to simultaneously complain about transparency, then rig the system so the only time you want to hear the truth is when it is affirmative or what you want to hear and not an accurate portrayal of the project situation.   It can be argued that you really need to hear the truth when things are not going good.

Not tools will save you this headache.  Tools cannot make you more transparent. That takes organizational culture and behavioral change and commitment.

More from the study on project management tool use.

Posted on: July 14th, 2015 by admin No Comments

In our last blog post on project management tools, we reviewed one of the findings from a study conducted by Software Advice, in their latest report.  That report stated that 60% of the prospective buyers are using manual methods[1].  We should not just disparage those companies that choose to go the manual route. Finding a tool that will work is a non-trivial activity.  These tools can be complicated and require training and can have a rather shallow learning curve; that is it takes a long time to gain a small measure of mastery over the tool.

Besides understanding your project management problem that you are working to solve, there can be complications associated with company politics.  I have seen these political disagreements derail any chance of quickly identifying possible tool candidates and work to assess the capabilities.

The study also goes on to rank the top reasons the first time buyers are looking at project management tools.  The top three are[2]:

  1. Need to organize
  2. Automate / streamline process
  3. Increase transparency

These three areas tell us something also.  Automating is not possible without tools.  It can be eliminated, maybe, but it cannot be automated.  Transparency is interesting also. we will take that discussion in our next post.

Project Management tools are not everything, but…

Posted on: July 13th, 2015 by admin No Comments

Why do we use tools?

We use tools to make our lives better. It would not be very fun to hammer a nail into wood with our hand.   Imagine the situation if we continued communicate via pony express. Sometimes, when we are not aware a tool exists, we may try to fabricate something.  We make tools out of available spread sheet programs or documentation writing programs.  I have worked at a globally distributed company that had a multiplicity of tools, some custom built and some even more unique.  These tools were used by a variety of constituent companies and none of these tools worked together well and some team members did not have access to some tools or the contents.  It was clear that a single Product Lifecycle Management (PLM) tool would have gone far in managing the work better.  That is why I was, perhaps not as shocked as I should have been when I came upon this report from Software Advice:

The study found that only 17% of buyers are currently utilizing a project management solution, and that a staggering 60% still rely on manual methods to track and manage projects.[1]

Poor reasons for getting a tool.

Acquiring a tool for the sake of the tool is not the way to work, however, neither is trying to turn a screw with your fingers. If there is a right tool for the way you work and your organizations objectives, it is incumbent upon management and organization talent to explore and consider how to introduce to your company. 

We will write more on this study in future blog posts.  Your input, experiences and opinion are greatly appreciated.  What do you think?  What stories do you have?


Product Development and Configuration Management

Posted on: July 3rd, 2015 by admin No Comments

Software Process and Measurement Cast podcast, Tom Cagley and Jon M. Quigley

Configuration Management: Theory, Practice, and Application

Configuration Management is a common thread that ties the various departments and organizations together, facilitating coordination of effort. 

New Configuration Management book

New Configuration Management book

Evolution of the Product Through Configuration Management

Posted on: July 2nd, 2015 by admin No Comments

Joe Dager’s Business901 podcast with Jon M. Quigley

Evolution of the Product Through Configuration Management

Product Management and Project Management Intersect at Configuration Management


Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO