8 posts categorized "Teams"

06/09/2011

How Much Organizational Buy-In Is Needed for Project Management Software Tools to be Successful?

IStock_000005461904XSmall_w
This is a question that I have been contemplating again.  Project management software tools need have buy-in to be successful.  That is especially true of management.  You need to have management buy-in, otherwise no one will use it.  It is not as much true of team members that are further down the "totem pole".  It is certainly great to get their buy-in and we should diligently seek that, but sometimes it does not matter how great a solution is, there will be resistance because it is different.

So do you need organization buy-in throughout an organization in order for a project management software tool to be successful?  Does the CEO need to buy-in to it?  Ideally, the CEO and the entire organization buys into both the software tool and the business processes it supports, and that does happen.  However, often times you might as well play the lottery, especially if it is a large organization.  You will have just as much of a chance of making it happen.  The question is...can you still get value from the tool?

The answer is...it depends.  How big is your organization and what do you want to accomplish with the tool?  Here are some principles for you:

1.  There must be a clear purpose for the project management software tool.  What are you trying to accomplish?  Understanding resource loads?  Providing visibility into project status?  Stopping tasks from falling through the cracks?  Centralizing information?

2.  There must be business processes that the tool supports.  The tool is only as good as the processes it is designed to support and automate.

3.  The purpose and processes must be associated with a team / group / department / organization.  In other words, are you trying to accomplish this purpose for your team?  Your group?  Your department?  Your entire organization?  Who is involved in the process?  Just your team?  Your department?

4.  Buy-in is needed throughout that sphere.  For example, if you are trying to understand resource loads for your team, then you need buy-in from the team, especially the leaders / managers of the team.  If you are trying to provide visibility into project status for the whole organization, then you need buy-in from the top of the entire organization.  If you are trying to use the tool to automate a process, then you need buy-in from those that participate in that process.

Do you agree or disagree?





06/07/2011

5 Principles For Project Teams To Work Better

I recently wrote a white paper on 5 Principles For Project Teams To Work Better.  One of the principles deals with automation so it is applicable to this blog on the implementation of project management software tools.  You can download the white paper at the URL below.  I would appreciate any thoughts or comments that you had!  You can comment or email blog@teaminteractions.com.

White Paper: 5 Principles For Project Teams To Work Better

 





05/11/2011

Addressing Workload Management to Improve Team Efficiency

This morning I wrote a post about workload management in the Flying Into Project Management blog, where we delve into lessons that project management can learn from the aviation field.  Every once in a while I will cross-post on this blog and I am doing so now.

This post talks about one of the factors in improving our team management and efficiency by looking at the concept of workloads.  Since teams are a critical piece of our projects and the resources we have available, it is a relevant topic.

You can read the post here.





12/13/2010

Should Everyone Be Required to Use Project Management Software?

I had an interesting discussion this morning with one of our project management software clients.  We were talking about their history with us and what has worked for them.  The conversation turned to the adoption of the tool by their users.

In the past, they did not require the use of their project management software system by all of their users, and they did not enter in all of their projects.  Some departments did, others did not.  What was the result?  There was no central visibility into all of the projects so the value of the tool to the organization was low.  Once they started implementing some accountability, and had all of their projects in the system, the value of the tool to the organization, and everyone, skyrocketed.  Why? 

There are two reasons that I see:

1.  They could then wrap a good process around the tool.  The tool in and of itself is of no great value without a good process around it.  The tool should support the process.  If you are only doing a half-hearted job at the tool, you can do a half-hearted job at the process.  Or you have one process for certain projects, and another process for other projects.  This is very inefficient.

2.  They have immediate visibility into everything.  This opens the doors to new things, such as being able to tell a customer the current status of a project, and even more importantly identifying constraints and problem areas.  This particular client does a lot of engineering.  They have a very constrained resource, namely a testing station that everything has to go through.  By identifying the workload for the testing station, they can schedule that work, flow out the rest of their projects, and thus accurately predict when projects will really be done.  They simply couldn't do this if the projects were not all in the system.

This brought up the question in my mind, should everyone be required to use project management software?  It is an important question because not everyone will use it if they are not required to do so.  As much as we would like to think that everyone will jump on board if the software is good and intuitive, that just is not the case.  Some people simply will do things the same way they have always done them.  No matter what.

Let me make a distinction that I am specifically referring to an organizational project management tool, such as a web-based tool.

I do believe the answer to this question depends somewhat on the organization, its culture, and its goals.  In the case of our client above, they have a fairly formalized process and scheduling is very important.  In their case, I believe that everyone should be required to use the system, otherwise they simply cannot accomplish their objectives.  I suppose there is a case to be made for an organization that is more informal and not as schedule-driven.  In that case, perhaps it would not make as much of a difference.  But even then, why use the software in the first place?  If your goal is to increase collaboration, what good is it if everyone does not collaborate?  Why get a tool to collaborate and not implement the process and discipline of collaboration?

What do you think?  When should everyone not be required to use a system?

 





11/19/2010

Systems Thinking

IStock_000000638838Small A project tool is not always a piece of project management software.  It can be a process or technique or system.  I recently read a blog post by Josh Nankivel on Systems Thinking.  It was actually a review of a book that Josh had read, but he brought out some interesting points.  As I read through these I again thought of the reasons that we decide to implement some sort of project management software.  What is our goal?

When we get right on down to it, is our goal not to make our project systems as efficient as possible?  To develop maximum output, to identify core causes of problems, to create predictability?  When I say "system" I am referring to the whole process or engine that causes projects in your organization to be completed successfully - your processes, tools, resources, techniques, and more.

Your project management software tools are there to support this system and should enable you to do things like:

  • Find root causes of problems
  • Identify problems and prevent them
  • Discover where performance is lagging so that efficiency can be improved

You should be constantly doing these things.  Read Josh's post and see how you are doing with systems thinking.

 





11/01/2010

Are You Insane?

What is insanity?  What does that have to do with project management software tools?  According to dictionary.com, one of the definitions of insanity is "extreme folly; senselessness; foolhardiness."  A definition that I like better is "doing the same thing over and over and expecting different results."  This has been misattributed to Benjamin Franklin, and it seems like no one knows exactly who said it.

Don't we do that - doing the same thing over and over?  What are you doing over and over and expecting a different result?  Or what new result do you need to achieve - and thus what do you need to do differently to achieve it?

Are you using the same old tools for project management and still fighting fires due to late or a lack of information?  Are there processes that are broken?

What can you change today to achieve a different result?





10/22/2010

10 Ways to Improve the Performance of Project Teams

We just released an updated version of our whitepaper, 10 Ways to Improve the Performance of Project Teams.  This is not a post specifically on project management software tools per se, but we are interested in working better - achieving our objectives through better project management and better project management tools.  I think you will find this helpful.  You can download the whitepaper here.

 





10/13/2010

Book Review: The Myths of Innovation

Cat 

I am a simple guy.  I like simple ideas and simple solutions.  I also am not fond of abstract ideas or recommendations that do not really accomplish anything.  I prefer those where I can get down to it and accomplish something.  So when I picked up Scott Berkun’s book The Myths of Innovation I’ll admit I was a little skeptical.  My perception is that a book that talks about innovation will be abstract and not practical.

I was pleasantly surprised.

Scott’s book opened up a new way of thinking about what it means to be innovative and to create new ideas and “things.”  He walks through our misconceptions of history and of how ideas are / were created.  He discussed some pitfalls that stifle ideas and innovation (if you are a manager or on a project team you will want to pay attention to these – they may dramatically improve your team).  He discussed the sweet spot of innovation and the value of good old hard work.

There was one topic in the book that I found ironic (granted on a personal level).  Interwoven in some of the discussions was a reference to Darwin’s theory of evolution.  These were not main points of the book, but nonetheless there.  My personal inquiry leads me to believe that this is an “idea” misunderstood and assumed, similar to other examples of belief noted in Scott’s book.  In other words, we take it for granted as being true.  That is a personal observation granted, but it got me thinking about one of his discussions on how culture and our environment play a role in the ideas that are generated and that grab hold.  I simply wonder how many of our current ideas are erroneous and will end up in a similar chapter of a future “ideas” book, simply because we do not challenge them.

There were a number of things that I did like, but the number one thing was Scott tearing down the notion that it is the geniuses or super creative people that come up with the great ideas.  On the contrary, each of us can and should be creating and generating new ideas.  And Scott provides the steps to do just that.  I will not spill the beans (get and read the book instead!), but it is simple, straightforward, and will motivate you to just start.  So many of us either do not work hard at something, we give up, or we think we cannot do it.  Think again!  One of Scott’s quotes from the book is that “you must create things to be creative.”

 I also liked his discussion on trust within teams and how important that is, framing problems differently to generate new ideas, and not being afraid to make mistakes and even fail.

This is a project tools blog related to using project management tools to facilitate better project management.  How does this book relate to that?  I see a few ways.

Projects are so often about solving problems, whether it is creating a better widget, redefining a key process, or performing a better service.  Ideas are critical to that.  I wonder if in the pursuit of project methodologies, techniques, and certifications we have lost the ability to simply generate new ideas to solve problems and get things done.  If nothing else, this book will challenge you as a project manager to bring more to the table, and free up your team to think of new ideas to solve problems.

We are also reliant on tools – whether it is “project management software”, spreadsheets, email, or whiteboards.  I believe there are some innovative ideas out there for how you can use your tools more effectively, and how those of us that develop tools can generate new ideas for better tools.

Finally, this will challenge you personally in your career to think differently and generate new ideas for how you can contribute to your organization or branch into new areas of your career or life.  And that can be a very good thing.

Pick up a copy of the book and I believe you will learn something.

You can download two free chapters to whet your appetite. Then once you’ve read those, you can grab the rest here: http://bit.ly/mythspb.

 

 

 






 

Subscribe

The EnterPlicity Project Tools blog covers all areas of effectively tracking, managing, and using your enterprise project data.

    

Subscribe by email:

 

What is EnterPlicity?

EnterPlicity is project management software that enables your organization to extend project management software tools to everyone, share any project information, automate key processes, and analyze project data in a single, easy to implement system.