48 posts categorized "Implementation"

11/02/2011

Five Things Project Management Software Can't Do

IStock_000000418676Small_2Do I think that project management software is valuable?  Yes, when implemented with a good process.  Implementing project management software will not solve all of your problems.  It can do a nice job of supporting your solutions, processes, and objectives.  But let's be sure we understand some things that it cannot do.  Here is my top five list:

1.  Project management software cannot enter data.  Your people still need to enter in actual data.  You have to make sure the data input is clear and relevant, and hold people accountable for entering in correct data.

2.  Project management software cannot make decisions.  You have to make decisions.  But project management software can provide you with the information to make informed decisions.

3.  Project management software cannot automate your entire operation.  Unless you have a very large budget for a very large, complicated system, you will still need to do some manual activities in the system.  It can automate some routine, mundane tasks (i.e. sending out notifications and producing reports), but it will not take the place of someone directing the operation.

4.  Project management software cannot eliminate the crazy report requests your boss makes.  But it can make it easier to pull the information needed for those crazy report requests.

5.  Project management software does not mean you don't need anyone to track your schedules.  Schedules do not magically appear in good format so that informed decisions can be made.  Someone needs to make sure they are being entered correctly, reports are setup correctly, etc.  Project management software can make this much, much easier so that you don't need to spend as much time chasing down and dissemanating information, but you cannot eliminate the need altogether.

 





10/07/2011

5 Questions to Answer Before Implementing Project Management Software

IStock_000007651615_web Project management software, like any software, needs to be implemented well in order to obtain the expected benefits.  Here are five questions to answer before you start implementing project management software (or to answer before trying to reinvigorate your existing implementation).

Why?

Why are you using this software?  You need to have the objective and end goal in mind.  Is it to solve a specific problem?  One of our clients implemented our software to help solve the problem of delivering projects to their customers late.  Is it to better manage resources?  Another one of our clients needed a better picture of resource availability and usage.  Both of these companies had an objective in mind which gave a clearer focus while they implemented the software in their organizations.

How?

How will you use the software?  Software systems can do a lot of things, but you shouldn't use those features just because the software does them.  Identify the features you are going to use that meet your objective(s).  This is where a focus on process is important.  I would even advise you to document the process that you want people to follow as they are using those features.  For example, how should people create new projects (i.e. they should fill out a form, use the x template, and assign resource roles)?.  Or which reports will be used to measure progress?  Determine how you will use the features.  This will also give you clarity in training so that you do not get into the trap of training strictly on features just because they are there.

When?

When will you implement which pieces of the software?  You may decide to phase in features and processes.  If you are an organization that is not used to using a tool like this (perhaps it has been haphazard to date), you may want to start off simple.  Perhaps your first goal is to simply get all of your projects loaded into the system and get people used to that.  Then you can tackle something else.  Also, when will you begin?  Does it interfere with any other key organizational events?  You do not want to implement software when most of your folks are busy with year end duties, for example.

Who?

Who will use the system and more importantly who will manage the implementation?  Do you need a full-time person to manage your implementation?  Unless you are implementing this across a Fortune 500 company, no.  Do you need to assign responsibility to someone to make this happen?  Yes.  Otherwise, it won't get done.  The easiest course of action is for people to do what they have always done.  You need someone to make the implementation happen and manage it appropriately.

What?

This is the favorite question that my kids ask.  I haven't figured out yet if it means that a) I am not speaking loud enough, b) they cannot hear well, or c) they are bluffing and wish they hadn't heard the question.  I have ruled out b with a simple test.  If I ask an important question, 62.3% of the time I will get "what?" as a response.  But if I whisper something about ice cream from across the room, 87.4% of the time they will demonstrate that they have heard me.

What does this have to do with project management software?  Absolutely nothing.  But how can you ask why, how, when, and who, without asking what?  And I couldn't think of a meaningful use of the question what, except for what features will we use, but I've already covered that so I better move on.

 

Be sure you ask these questions before you implement project management software.  You will find your implementation much more focused with a quicker ROI.





07/26/2011

4 Questions to Answer Before Presenting Project Management Software

IStock_000000077653_L2_smal We have covered a lot of ground in this blog about how to implement software, best practices, even how to select it.  One thing that we have not covered much is how to get buy-in from other people to implement project management software tools.  This can be hard to do for several reasons:

  1. People do not like to change.
  2. No one wants to take on another effort.
  3. People are too busy fighting fires, much less trying to address the root causes of the fires.
  4. People think what they are doing is just fine.

Just this morning I read a blog post by Ted Hardy at the Better Projects blog.  In his post, Ted walked through how he brought an idea to his team and achieved their quick buy-in.  I want to expand on Ted's post and give you four questions that you need to answer before presenting project management software to your organization.

What's the problem?

If you are going to implement project management software because it sounds like a good idea, don't bother.  It has to be tied to a problem.  What problem will it solve?  How will it provide value?  Ted's value proposition was that his idea would provide data that they didn't have today in order to solve quality problems. The problem should be your focus and will drive how you present it as well as how it is implemented.  Perhaps you have projects that are continuously late and no one knows why.  Perhaps you are making promises to your customers that cannot be kept, because no one has the data to say when something will actually get done.  Perhaps you know you have resource bottlenecks but have no data to prove it or to show where, how, and why the bottle-necks are occurring.  Perhaps you have documents or other information strung all over the place in spreadsheets, whiteboards, files, and post-it notes so no one can find key information when they need it most.  These would be examples of real, definable problems on which you can focus your "pitch".  If you have a solution that can solve a real problem, that is a real value-add.  And that is much easier to present than a vague benefit.

What's the process?

Do not focus on the project management software tool itself and its "cool features".  Focus on your process.  The software is simply a tool to implement, run, analyze, and improve your process.  When you present this, you don't even need to focus on "implementing a project management software tool".  You can focus on implementing a process (and using a tool to help you do that).  The software can and should take a backstage approach.  If there is too much focus on the software tool itself, than there is not enough focus on the process and the underlying problem.  So what is the process that can be implemented (or changed) to fix problem x (defined above)?

What's in it for them?

Why should people do this?  What will they personally get out of it?  Perhaps it is some key reporting to save them from doing hours of manual data manipulation.  Perhaps it is to remove a headache that plagues them day in and day out.  Put yourself in their shoes and be sure you understand and can articulate how they will specifically benefit.  You could mock up some sample reports to show people (be sure they will realistically be available), and even quietly get feedback on them before even expressing your idea ("do you think it would be helpful if you could get information like this?").  Go to lunch with people and explore what problems they have and what would be a real benefit to them.

How will you implement?

Do you know what steps you will take?  Will you phase it in or try and do everything at once (phasing it in is highly recommended)?  Will you have a pilot group?  Who will be in that group?  What processes will you implement at first?  What will they look like?  What problem will they solve immediately?  What will people be able to get out of the tool right away that will help them?  How long will it take?  How much time will it take from people's day?  These are all questions that you need to answer before making your presentation.

The bottom line?  Be prepared.  In Ted's post, he had an idea for something that would really help the team and the organization.  He did his homework and explored the idea and what it would take.  But even then he didn't present it.  He let it ruminate for a while which gave him time to think it through and thoroughly understand his approach before presenting it to the team.  It worked and unless you are dealing with a dire situation that requires an immediate solution, it's a good approach.

 

 





07/19/2011

Key Steps to Achieve Accurate Resource Utilization Reporting in Your Project Management Software Tool: Part 6/6

IStock_000004563504X_web This is the last post in a discussion on how to achieve accurate resource utilization reporting, and thus good resource management, in your project management software tool.

In part 1, we discussed the key of capturing all of the work to be performed by your resources (people for the purposes of this series).

In part 2, we discussed the key of accurately capturing when the work will be performed.

In part 3, we discussed the key of capturing the effort as opposed to strictly the duration of the work.

In part 4, we discussed the key of capturing the true capacity of your people.

In part 5, we discussed the importance of process, discipline, and the right tools.

Now let's pull it all together and wrap up this discussion.  There are some random but key, underlying points to keep in mind as you work towards building good resource utilization statistics.  Here they are.

Maintaining Resource Utilization Statistics Is Not Easy

Do not go into this blindly.  This is not an easy, little additional task to do.  It requires a fair amount of work and it requires really everyone to do their part.  It can be well worth it in the end, but go into it with your eyes wide open.

You Must Know What You Want

What are your objectives?  What do you need to see when all is said and done?  If it is to feel good that you know what everyone is doing, don't bother.  If it is a specific goal, such as to increase the utilization of your key resources, then go for it.  Similarly, this will help you determine the level of detail you need (and thus the level of maintenance effort required).  If you need to make day in and day out decisions on resource assignments, then you need to be very detailed and go all out.  If you simply need to make monthly presentations to management, then you can probably relax on some of the detail and strike a good balance between getting enough detail and getting more than it's worth.

Work Backwards

I would map out what you want to see in a report when all is said and done, and then work backwards to collect the data that will enable that report.  In other words, start with the end result.  Once you have that, go backwards.  If your end result is to see a % figure of utilization for each week for each resource, then you can start to map out a process to collect utilization figures each week.

Implement in Phases

You do not have to bite off everything at once.  Start small and work from there.  Create a long-term plan for getting to your ultimate objective.  You may simply start by creating better work breakdown structures (then you could even do something like assign a generic / default percent of effort for a rough estimation of everyone's utilization).  Then after everyone is comfortable with that, you may start adding effort estimation to your work breakdown.  This tends to work better than to do everything all at once.  If you have to do everyone all at once, then be sure and run a pilot.  Choose a few projects and a few people and work through the process.  You will find that you will change and tweak it to work out the kinks - and better to do that with a few people than with everyone.

Resource utilization can be a powerful tool, even a differentiating tool because it is not easy for organizations to do it well.  Write me at blog@teaminteractions.com with your own stories and insights as you implement this in your own organizations.

 

 





06/22/2011

5 Things You Are Not Doing (But Should Be) With Your Project Management Software Tools

IStock_000005289430_web Almost all of us have project management software tools that we use on a consistent basis.  It may be true project tool, a spreadsheet or even email, but it is still a software tool we use to help manage projects.  Here are 5 things that you are probably not doing right now with your project management software tools (but you should be).

1.  You are not looking at trends or historical data.

Most people are consumed with the present and the future.  Which tasks need to be done and which are coming up?  Trends are important.  If you do not look at trends or historical data, you will never get better.  Trends tell you tasks that are typically not completed on time, how much time items really take, who your resource choke points are, and even opportunities for process improvement.

2.  You have not matched technology and process together.

Technology only provides significant value-add when it is married together with a good process.  The technology should support that process.  Many people implement technology without a good process in mind.  In other words, they are focused on the features of the technology (aka "a way to schedule our projects") instead of being focused on implementing their process.  Or they have implemented technology without a documented process in the first place.

3.  You are not taking advantage of automation capability.

Even organizations that have sophisticated project management tools tend to not take advantage of the automation capabilities in the tool itself.  They still spend an enormous amount of time doing things manually that could be done in more of an automated fashion.  For example, you may be tracking your schedules in a tool, but you are also continuing to fill out documents (with duplicate information) and passing them along in your process.

4.  You do not have a meaningful dashboard.

Organizations may have a dashboard, but many organizations do not have a "meaningful" dashboard.  Either no one is looking at it or when they do look at it, it does not tell them what they need to know to make decisions.  This is because no one has spent the time to discover what information is truly meaningful or the data in the tool is not up to date.

5.  You do not have anyone overseeing the tool set.

Tools are like anything else.  If you do not spend any time overseeing the tool, it will not be used effectively.  That means that you need to have someone whose responsibility it is to make sure the tool (and the information in it) is clean and useful.

Are you guilty of any of these?  Most of us are not perfect in the use of our project management software tools.  Pick one and work on it and see what results you get.

 





06/20/2011

4 Quick Thoughts on Buy-In for Project Management Software Tools and Processes

IStock_000004563504X_web Following up on my last post on how much buy-in is necessary for a successful project management software tool roll out, a question remains: how do you achieve buy-in?  This is not an easy question, but here are four quick thoughts on how to go about it:

1.  Accept the buy-in that you can get.

In other words, be content to start small.  You may not get the home run, organization-wide buy-in right away.  Start where you can and prove your ideas.

2.  Plant seeds.

Sometimes an organization is just simply not ready yet.  But you can plant seeds in a professional, courteous, and tactful way.  Forward an article you read as an idea for something in the future.  Let someone see the results you are getting in your own small area.

3.  Bide your time.

Sometimes the timing is just not right.  Perhaps there are too many things going on for the organization to buy-in right now.  Bide your time.  At some point, an event is going to occur which will put the organization in a better position to be open to your ideas.  Perhaps a new, key manager comes in who is more open to the idea, or perhaps a major failure occurs and there is a call to action.  You never know when or how quickly things can turn.

4.  Be prepared.

Know what you want to pitch and how to pitch it.  Show what you are accomplishing in your own area.  Show what other organizations have achieved.  Have a process mapped out for how it could be done.  Be prepared for the right time.

 





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/03/2011

More Tips for Great Dashboards in your Project Management Software Tools

As a follow-up to my post from earlier this week on keys to an exceptional dashboard, I came across an article in CIO magazine by Chris Curran on "10 CIO Dashboard Tips."  It is geared towards an IT audience, but has several good tips nonetheless.  Here are a few that I liked:

Make sure you can actually collect the data you want to measure.

It does not good to show an earned value statistic, for example, if you do not have good work breakdown structures.

Begin by summarizing and analyzing data you already collect.

You may find some good analysis for your dashboard right off the bat.

Create a report to perform checks and balances on core dashboard data to increase credibility.

The companion report would provide some detail from which the dashboard data is derived.  This increases everyone's confidence in the dashboard data itself.

Have a printable version of the dashboard.

This way people can easily take the information with them.

 

You can read the full article with all the tips here.  Enjoy!  And have a great weekend!





06/01/2011

5 Keys to an Exceptional Dashboard in Your Project Management Software Tool

IStock_000003110526_web Dashboards are not created equal, even dashboards that display the same information.  One organization may have a vibrant dashboard that is used by everyone reliably.  Another organization may have a stagnant dashboard used by no one.  What makes the difference?  What are the keys to implementing a good dashboard?

Here are five keys to implementing a fantastic dashboard in your project management software tool:

1.  Keep it Simple

Some dashboards are overly complicated with too much information, or information that is too complex.  Keep your dashboard simple both in terms of the layout and the information presented.  Do not make it too complex.  Someone should be able to glean significant information from the dashboard in a matter of seconds.  If it takes a lot of effort and time for them to glean information, it will not be effective.

2.  Your Dashboard is Only as Good as the Data You Enter

It does not matter how fancy of a tool you have, how nice the reports are, or how fancy the presentation is if the underlying data is not solid.  In other words, all a dashboard does is present data that has been entered by people.  If people are not entering data correctly, or are not regularly keeping the data up to date, then your dashboard will be useless.

3.  Stay High-Level with the Ability to Drill-Down Into More Detail

It is easy to get lost in the minutiae of adding all of the significant detail to a dashboard.  That is not the purpose of a dashboard.  The purpose of a dashboard is to provide a high-level overview so that the viewer knows what action to take.  The viewer may then need the ability to drill-down into more detailed information, but this information should not all be displayed in the dashboard itself.  For example, it may be important to the viewer to know which projects need attention - perhaps a green / yellow / red indicator is attached to each project or portfolio.  However, the individual tasks, milestones, or issues that are causing the indication would not normally be displayed.  Those would be available upon the viewer drilling down further.  The exception to this would be a team member-level dashboard whose specific purpose is not to provide insight but to communicate a lot of detailed information, such as their current tasks.

4.  Only Present Actionable Information

There is a tendency to put information on the dashboard because it is neat and because you can show off the fact that you know the percentage of tasks within a portfolio that begin with the letter "M", started the Monday after a holiday, and the number of letters in the name is divisible by 2.  However, no one is going to use this information so there is no reason to display it and no reason to collect it.  The dashboard should be a tool where information is displayed that viewers will consider relevant, that they will actually look at, and that they can take action on.  Ask yourself whether the information in your dashboard meets this criteria.

5.  Don't Forget Training

 No matter how simple your dashboard may be, do not assume that people understand what they are seeing.  Sometimes there are nuances in language or procedures that are interpreted differently by different departments, people, and organizations.  Provide some training so that people know they are using the information in the dashboards appropriately and effectively.  I am not talking about formal training, but either holding periodic brown bag lunch sessions and / or providing a one-page cheat sheet on the information presented.

What other keys have you seen make a dashboard effective?

Happy Dashboarding!





05/26/2011

How to Make Automation (or Project Management Software Tools) Work: Part 2

IStock_000010045800_web In my last post, I talked about learning from the aviation field and how they use automation technology effectively to fulfill their objectives.  We are taking that and applying that to how we could use automation technology in project management (aka project management software tools) effectively.

You can read the first post here.

Let's turn to some practical lessons that we can apply:

Provide Training to Your Team, Managers, and Stakeholders

Can you imagine a pilot flying a new airplane without being thoroughly trained on the automation technology in that airplane?  The consequences would be serious.  Yet we provide tools of a sort to our project teams, managers, and stakeholders without the training for them to use the tools effectively.  As I mentioned in the last post, people have to build a trust in the system.  Training plays a big role in building this trust.  Training should also be process-driven.  In other words, most people do not need to know all the ins and outs of every feature in the system.  They just need to know how to perform their job in the tool.  That means that you do not need to send everyone through two weeks of formal training.  But you can and should hold some informal sessions (such as brown bag lunch sessions) and produce some organization-specific documentation on how they should use the system.

Document and Understand Your Processes

Technology without a clear purpose just frustrates people.  Technology should support your key processes, make them easier to follow, and provide insight into the execution of those processes.  That means that you need to know what your processes are.  And you need to communicate those to your organization.  You cannot assume that everyone knows through some type of "tribal knowledge."  You need to have a set of documents that details out the key processes that you expect people to follow, such as how to initiate a new project, how to assign staff to that project, how to submit status, how to obtain a client's approval, and so forth.

After that, you can look at your technology and how to implement those processes in the technology tools that you have.  In fact, within your documented processes you could include steps on how to fulfill those processes using the tool.  You end up with a set of "standard operating procedures" that everyone understands.  Do you see the difference?  This is far more effective then simply getting a tool because we are "having a problem with schedules slipping."  After doing this, you may determine that you need to use the tools differently, that you need different tools, or that you need to simply train people on the proper way to use the existing tools.

Reduce Complexity

Automation technology should not be complex.  If there are a lot of steps that a person needs to follow to perform something in a tool, then it is too complex.  Automation technology should do just that: automate key functions that would take a lot of time otherwise.  This could include generating a report, collecting status, identifying resource overloads, and others.  Your tool should make these key items in your process easier.  Part of this means that you should not overreach and make your tools overly complex.  Keep them as simple as possible.  Said another way, set them up so that you can run your processes and get the information out of them that you need, but no more.  Don't do things just because you can in the tool or because it is "cool."

Provide an Expert

Someone in your organization should be an expert in the tool.  They should understand how to implement your processes in the tool, what the tool is doing, and how to extract information out of the tool (although everyone should understand this).  They should be a resource for others that are perhaps new to the tool.  If you have a larger organization, create a network of these people that can provide assistance to team members, and ensure the tool is being utilized properly.  In other words, don't leave people to fend for themselves.  And do not always rely on the vendor for understanding how to use the tool.  This is going to be a key part of your processes so make the investment to have someone inside with in depth knowledge.

Technology in project management can be a valuable, game changing piece when implemented well.  Try these lessons in your own organization regardless of the particular tool(s) that you may be using.

 

 






 

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.