Category: Articles

Home Articles ()

Building the Dream Team for Your Project

I’m happy to include a guest post today from University Alliance and the Project Management Certification prep program at Villanova University.  I hope you enjoy it. – Chris

As most project managers know, assembling the best talent for a project can give the project a quick, successful start. Knowing how to build the best team can be a challenge though, as it requires evaluating talent and comparing it with the needs of the project before the first team meeting has even happened. Moreover, the project manager has to be ready and willing to make adjustments as the process moves forward.

Define the Needs
The first step in building a project “dream team” is to define exactly what the needs of the project are. Thinking through the key attributes that are required for success is a helpful exercise. Do team members need to have amazing communication skills, a specific technology background or a can-do attitude? Knowing this in advance will assist in finding the best fit for the team.

The same question turned upside down is also critical. What attributes will detract from the success of the project? Too much ego, a negative attitude or poor communication skills might get in the way of the rest of the team. However, know there is room for those who don’t quite match up to the list of key attributes, but do have other intangibles. If everyone else on the team is a great communicator, a more reserved team member might be positively influenced. The goal is to match up complementary skills and to allow for growth.

Working Together
The next step to effective team building is to determine if the group in consideration will work well together given their individual personalities and attitudes. This is the time to consider the old adage, “too many cooks spoil the soup.” If the entire team is made up of strong leaders, some may experience conflict. Additionally, check to see how individuals are at receiving feedback. Honest feedback, given carefully, can help move a project along at a strong pace.

Another area to investigate is how reliable each team member is according to their previous team leader. Most projects will face bumps in the road, so it is imperative to know that the team can reassess and adjust when problems arise. Think through whether the people on the team will put forth the extra effort to get the project done on time. That level of teamwork can make or break a project.

Adjusting Over Time
Once the evaluative process is complete and the team is running, check to see if there are any gaps in capacity. If there are, then the manager should quickly bring in new team members to fill them to prevent slowdowns in work or morale issues. During that time, tracking the performance of the team is the next challenge. While scope and personnel may change over time, the project still must have a beginning, middle and an end. There should be clear goals and deliverables that team members can understand as well as undertake. Rotating team members as needed and removing those who are under-performing will help keep the team streamlined. Adding new talent for particular phases can also help to increase the efficiency of the project.

Realistically, creating a successful team is much more than simply putting people into a room and asking them to complete a task. By carefully considering the talents of team members, their attitudes and aptitudes, it is possible to create a team that can handle any project.

Erin Palmer is a writer and editor for Bisk Education. She works with Villanova University’s project management certification courses, which prepare you for PMI certification.

An all new and improved Primavera Solution Portal

We have many clients who use TimeControl with their Oracle-Primavera system.  Perhaps it’s no surprise.  TimeControl has integrated with Primavera since 1997 with P3 and we’ve maintained that link all the way up to the most recent P6r8 release even once Primavera was purchased by Oracle.  Primavera clients who need a single timesheet to update not only the task progress in Primavera but also Payroll, Billing, Finance, Job Costing or HR have looked to TimeControl to provide multi-purpose timesheet functionality that will allow a single point of timesheet entry and multiple back-end uses.
Our relationship with Primavera goes back to 1997 and our relationship with Oracle separately also goes back to 1997 when TimeControl was first able to store its data in either SQL Server or Oracle (We now also support MySQL which is coincidentally also owned by Oracle).  So the relationship has many facets and runs deep.
We’ve done a little work to remake our TimeControl and Primavera Solution Portal with a range of new materials that we hope you’ll find useful.  Aside from a remake of the portal itself, we’ve got new factsheets, slide presentations, white papers and an all-new on-demand webcast that shoes TimeControl 6 and Primavera’s P6 interacting back and forth.
The integration options between TimeControl and Primavera are extensive.  Not only can you bring into TimeControl Primavera tasks, resources, steps and assignments, you also have abilities on how to match employees to generic skills and Primavera codes to TimeControl user defined fields.  Updating your Primavera project data with TimeControl timesheets is incredibly flexible.  You can update hours and costs, Primavera Step progress, ETC, Financial periods and more.
The new and improved TimeControl / Primavera Solution Portal covers some of the benefits of integrating these two world-class tools including:

  • Automated Business Validation Rules
  • Extensive Rate Management
  • Management of Vacation, Sick Leave, Personal time banks
  • Management of Banked Overtime
  • Included integration with P6 and other project systems
  • TimeControl Mobile interface for tablets and smartphones
  • Missing timesheet management
  • The Matrix Approval Process for Labor Actuals™

Access to the portal and its resources is free.  Find out more at www.timecontrol.com/solutions/primavera.

Enterprise system best practices article

My latest article on best practices for enterprise systems has just been published on Microsoft’s TechNetYou’ll find that column and a number of others on how to get the most out of selecting, planning for and deploying enterprise project management software in the Microsoft Project Server 2010 home page area of TechNet. This article looks at some of the key success/failure criteria to any enterprise system including, of course, EPM Systems.  Those factors include: finding a business owner, knowing what problem the system is supposed to solve, making sure it’s part of your enterprise technical architecture and implementing change management.  Go to Microsoft Technet’s Project Server 2010 page to read the article.

Doing two things at once can be too much

One of the most common problems that organizations doing a big enterprise project management or enterprise timesheet deployment run into is trying to do more than one enterprise deployment at once. You would think that no one would deliberately put themselves into harm’s way by doing this but it happens often and that’s partly because of how insidious the problem is.

The road to trouble is paved with good intentions
Imagine if you will, being in a conference room in the very earliest days of an enterprise system deployment. The world is full of possibility. You’re working with management to identify key gaps in your organization’s processes. You’re looking at a myriad number of tools that promise to solve all evils. You’re narrowing down how you’ll attack the business challenges with the proposed system.

As you all look together at the processes that will be affected, it occurs to you that one of these processes reaches outside your original mandate. Perhaps you’re looking at creating a resource capacity planning system but it becomes clear as you design that solution that you’ll need to change the current time and attendance system. Or perhaps you’re creating a work management system and you realize that you really need to update the old CRM system. Or, perhaps you’re changing the way you do billing with a new ERP and you realize that you really need to update the document management system.

It’s the easiest thing in the world to let your mandate go beyond its borders and it’s the easiest while you’re in that honeymoon period of designing the new enterprise solution that you started with.

“Let’s just include that 2nd system while we’re doing the first one,” says one well-wisher and now you’ve got not one but two enterprise systems to deploy.

Being pulled in two directions
Enterprise systems are change management projects. What that means is that they’re less about the particular functionality included and more about how they change business processes. By their very nature, enterprise system deployments reach deep into the operational behaviour of the organization and changes it to something that is hopefully more productive. Virtually any enterprise system can have this effect and the effect can be far reaching. A CRM system doesn’t just touch the sales people. It can also touch production, marketing, engineering, support and, of course, management.

With any enterprise system, we must go to senior management and ask what they wish to accomplish. My standard question for management is, “What business decisions can you not make now or can you make only with great difficulty, the making of which would be improved with this system?” That’s true for enterprise project management systems but it should also be true for virtually every system.

If you aren’t going to improve business decision making or operational efficiency in some manner, then there’s little point in deploying such systems.

But when we try to deploy two such systems simultaneously, we run the risk of pulling management in two directions at once. Even if the end result seems like a rational flow of decisions from Point A to Point B, the deployment of one of these systems will change behaviour and not just of management but of everyone the system touches. When we deploy a second system before the effects of the first stabilizes, not only will the second system be almost impossible to get established, the risk is to destabilize the first system as well.

The most common result is a complete failure of both systems.

Let’s take an easy example to see how this happens. An organization sees the need to improve efficiency in the area of project management. They decide to deploy a new enterprise project management (EPM) system to do so.

At the same time, the organization sees the need to improve resource management and decides that this can be done by deploying a new HR system, affecting all employees.

The two projects seem mutually exclusive and, indeed, for some time, the deployment teams might not even be aware of each other.

As the design of each of the enterprise systems evolves however, the changes driven by the design and deployment of the new systems start to run over each other.

The EPM system designers request a list of all departments, staff approval hierarchy and skills for populating the EPM system. These lists are delivered to EPM.

Over on the HR system deployment, a need has been revealed for better definition of departments staff hierarchical staff management and skill definition. The departments are realigned and redefined.

The HR changes are revealed to the EPM team who have already moved forward on their structure reworks the area that is affected by the changes in HR.

HR is informed by the EPM team that they will be implementing a resource management calendar for EPM and will require all vacation definitions updated weekly. They also send a list of new skills to augment the existing skill set.

HR has already redesigned the skill set for employees and the new definitions by EPM don’t fit. They begin to re-re-design the skills area of the new HR system.

And so it begins.

The most likely outcome is that a certain level of frustration will be reached and the original notion of integrating the EPM and HR data at the points it touches will be abandoned. Each team will go its own way. This might reduce or eliminate a key element of the expected benefits of the new system.

A less common but usually more damaging outcome is that as the frustration of the back and forth changes increases, someone in management figures that this could be resolved by putting both initiatives into one monstrously big initiative and working the projects together. This is rarely successful.

Moving from in parallel to in sequence
For most business initiatives, working multiple tasks in parallel is highly efficient. Deploying multiple enterprise systems is not in that category. When it becomes clear that there are two enterprise system initiatives that can touch each other, the most prudent action is to advance one of them and slow down the other.

Determining which enterprise deployment should go first will not be a popular task. It does, however, offer a great opportunity for benefit because this type of decision can really only be made by senior management.

One of the leading causes of enterprise system deployment failure is the absence of management involvement. Technical and operational personnel are often given deployment projects without direct involvement from senior management to determine what benefits are expected from those systems. When two such projects get underway at once, it’s a good moment to re-involve management in the process to identify what is expected by the organization from each system so that a decision can be made as to which one should be done first.

Some of the decision making criteria for deciding which system should go first might include: expected benefits, costs, return on investment, speed to deploy, severity of impact on existing processes and risk.

Only once the first project is in production and is stable should the second project’s design restart. A stable, in-production system is one where the organization has fully adopted its use, has changed its processes to adapt to the new environment and where the benefits of that system are already being realized.

In the meantime, if your project is the one that has been slowed down, all is not lost. Knowing that you won’t be able to count on a shiny new enterprise system to solve your problems sends you back to the drawing board to think of how to solve your problems without it. We’ve seen countless examples of where an organization realizes other ways to improve their processes while waiting for the new enterprise system deployment to restart.

Whether your enterprise project is going first or going second, it’ll be better than having it go together. Doing two enterprise projects at once is a worst case scenario.

 

Eyes too big for the stomach

Eyes-Are-Bigger-Than-My-StomachWhat is it about Enterprise Project Management system deployments that make them seem like an appetizer rather than a big meal?

Just like people who look at the menu when they’re very hungry and order the soup, the salad, the big steak with fries and then throw caution to the wind to pre-order a huge piece of pie, I often encounter senior managers who are struggling with an EPM system deployment that has turned out much bigger than they’d ever expected.

When you boil it down, the chief cause is often embarrassing to who is inevitably the most experienced project management person in the organization; this chief cause if is often a failure to plan.  Those who had coolly scoped the project and determined just how far advanced the organization was towards the perceived solution, they’d have probably backed up to regroup. 

Unfortunately that’s not always so. 

Even project management systems need some project management when they’re deployed.  Measure twice and cut once is advice given to carpenters but it could just as easily apply to project managers starting an EPM systems deployment.

Enterprise systems best practices

I mostly write about enterprise timesheet or enterprise project management systems and the most common phase of deployment that I talk about with such systems would be either the selection or configuration phase; talking about the strategic perspective.  This article is much more about operational practices and isn’t specific just to enterprise timesheet or project systems but about enterprise systems in general though the subject matter certainly relates to enterprise timesheet and project systems.
When we encounter deployed project systems or we talk to existing clients who have our TimeControl timesheet system, we often ask questions about how the organization deployed and have supported the system and its environment.  When we got started in the industry, these were simple conversations because the software we’d install would always live on the end-user’s PC and care of the system was always a local concept.  These days that’s rarely the case.  Enterprise systems are simple at the interface or display level where end users can typically access the functionality through a web browser in what looks like any other web page.  As simple as these systems might be in front is as complex as they might be in the back.  The technology required to display that interface likely has numerous layers, depends on multiple sources for the technology and infrastructure and if that’s not enough, is probably being updated all the time.
But, there are some basic best practices that can give you the best chance of maintaining a high degree of reliability in your enterprise system:
Find an owner
In fact, we have to divide this into two owners because any successful enterprise system has both a business owner and a technical owner.  Only when the business owner is an executive in the IT department and the enterprise system is primarily for that department can the owner’s be the same.  So, let’s take this in two parts:
Find a business owner
This person should be an executive level or senior management level person who has a vested interest in the results of the system.  The benefits that the system must deliver or the business challenges that the system must overcome will have to be benefits and challenges that affect this executive directly.  And, before someone even says it; no, typically it can’t be a committee or multiple people.  The responsibility has to lie somewhere.  This person might also be the

executive sponsor for the implementation of the system but might not be.  Often the executive sponsor is not the ultimate business owner of an enterprise system.  Even after the deployment project is over, the business owner will still own the system and, should they no longer require it, either another business owner needs to be identified and must commit to the system or the system should be retired.

Find a technical owner
For enterprise level systems, just having a technician available is insufficient.  Remember, enterprise systems depend on many layers of technology.  The technical owner must be a senior enough manager or executive in the IT department that they will be able to immediately interact with the owners of those other layers of technology.  That may include senior people who own the database, the database server, the application server(s), the networking, the Internet connection, the firewall, other Security systems, the client-level operating system image. Someone senior must be able to represent this enterprise system to those managers who control other aspects of the environment.
Be purposeful
Make sure that the enterprise system a) has a purpose and; b) is fulfilling its purpose.  All too often enterprise systems are acquired for the wrong reason and it falls to someone in IT to look for a purpose to apply the system to.  The person signing off on the business purpose for the enterprise system should be the business owner though others might be involved.  I always ask such executives a question I’ve used for years, “What business decision can you now not make or can you only make with great difficulty, the making of which will be enabled by the deployment of this system?”  Once the business requirement (note that I didn’t say the desired functionality) is

settled, make sure that the enterprise system is actually fulfilling that requirement.  We get a lot of people who have a shopping list of functions but little understanding of what they’re trying to accomplish with them.
As the organization evolves, make sure that the business owner comes back to this basic concept.  Just the deployment of an enterprise system can fundamentally alter the business it is deployed into so it’s not surprising to find that the organization’s requirements for a system can change.
It is common to come into an organization several years after an enterprise system was adopted and deployed only to find it impossible to locate someone who knows why it is important to the organization.  The system is in use to be sure.  It is being carried forward on sheer inertia but the purpose has been lost and the executives who benefit from it every day don’t realize where that benefit is coming from.
Get it into your enterprise architecture
Several years ago I remember going with one of our technical staff to an upset client’s location.  The deployment of an enterprise system we had sold them was unstable and causing all kinds of upset.  While there in person, we asked to interview a number of technical personnel, tracing the system back through its layers.  When we got to the database layer, we were stunned.  Instead of being one of the organization’s standard database servers, the database on which they’d installed the system was on an end-user’s PC. Every time they rebooted, turned the PC off or installed something, the database would become unavailable.  This affected literally hundreds of end users.
The organization was a large one so there was no lack of enterprise servers or infrastructure to rely on.  In this case, the problem was easily fixed.  It was a good lesson though.  Is the system you are deploying being woven into the existing corporate infrastructure on which the organization may have spent an enormous effort getting stable, being reliable and being secure?
Back it up
I know, this is silly right?  Amazingly and unfortunately it’s not.  Enterprise systems can be notoriously complex to back up as they may depend on multiple aspects of the system to be backed up at the same time.  There is the basic data of course, but also the meta data, configuration data of the implementation and any related data from ancillary systems that might have to match the system might have to be part of the same backup scheme.
And just backing up isn’t enough.  When the systems change or are upgraded, do a database restore at least once.  I remember years ago being with a client who we had helped design their backup strategy for.  He shut down the server, pulled out the hard disk, put in another hard disk and then looked at us and said “There.  The hard disk just crashed.  That’s a newly formatted hard disk.  Please restore my system.”  I was taken aback but moreso because I realized how good a request it was and the more I thought of it, the more I realized how shocking it was that no one had ever made the request before (or since).  So, do a restore test at least once.  We were able to restore that system by the way, but it didn’t go back in as cleanly as we’d suspected it would and we had to update our backup procedures.
Staging/Production
“All the world’s a stage, And all the men and women merely players;” said Shakespeare a long time ago.  In this case those stage is more about staging and that’s key to for any enterprise system.  Once the system is in production, you will want to try new configurations, add new customizations, try new reports, links, fields and other changes.  You’ll have updates and upgrades and all of these should be tried first in a staging or development environment before they’re inflicted on the users in the production environment.  Something as basic as a browser update or a database update can throw enterprise systems for a loop so make sure you keep and maintain a staging environment that’s separate from a production environment.  In this day and age of virtual servers this may be easier than it might have been in the past as an entire environment can now often just be cloned from the production system but that may be easier said than done depending on how you’ve deployed.  Remember lots of different parts of the technology puzzle may be referenced even though you’ve copied an entire server.
Monitor, monitor, monitor
There are lots of points of oversight that can be used to monitor an enterprise system. First of all, making sure it is “up” or available is critical and ensuring that the appropriate technical staff are notified as quickly as possible if it is ever not available is also essential.  Thankfully there are many tools on the market for ensuring that the system is functional and available that can automatically notify technical staff even if end users haven’t noticed the problem yet.  But there are other aspects of monitoring

that are also important.  It is good to keep a watch and a log of the health of the application including the amount of memory it is using, the amount of the CPU(s) it is taking up, any errors that the system may have reported even if it recovered from them itself, any restarts of the server required and the relevant health of other elements of
the technical infrastructure.  Knowing, for example, that the Web Server is having technical issues might be very important to maintaining the availability of your enterprise application.
Even small changes are changes
The technology on which enterprise servers are based is changing day by day.  It’s impossible to avoid all of these changes. Server operating systems often receive updates every few days, databases often receive updates every few weeks. Client operating systems and the browsers and their add-ins get updates every few weeks.  Any part of the chain between the data and the end user is a potential point at which the application can break down so create a structure to manage changes throughout the entire stack of technology.  This can be a challenge as many different enterprise applications may depend on similar aspects of the stack.  We had one client who innocently updated their own enterprise project management system awhile back only to find that their entire collaboration server was brought down.  The effects were devastating and took days to

reverse.  At another organization, we had a client who had updated another enterprise application to find that it absolutely required all users upgrade their browser version only to discover that other enterprise applications already in use at the company did not support the more recent browser version.  It was the proverbial rock and the hard
place.  In the end, they had to roll back the upgrade of the enterprise system and wait until all the enterprise applications could move forward with a new browser upgrade.
Sometimes it’s better to look integrated than be integrated
Sales demonstrations always make the integration of multiple tools look so easy. Hey presto, the data starts here and ends there!  Establishing a link between disparate tools is tough enough and we always recommend that both systems be in production and stable before any links are established.  Once they’re underway however, it’s even more important to monitor any changes of the two systems with a mind to making sure they will continue to link properly.  With any upgrade of either system, there may be data changes, structure changes or different technical requirements.  There may also be new features and benefits that are possible but make sure the existing linking functionality is tested in your staging environment before it’s rolled out to production.
Document, document, document
The people who were there when the enterprise system was selected and deployed won’t be in those roles forever.  In fact, if they did a great job, they’ll be off managing the next enterprise deployment the organization needs.  So, documenting the configuration decisions, the projected benefits, the operating expectations and parameters that were used to make those decisions is essential.  Others in the future will be looking at this system and scratching their heads saying “What were they thinking?”  Make sure you tell them.
Enterprise system documents should be living documents that are updated with every upgrade, each change in business or technical owner or any major change in either the operating structure or the business requirements.
Look before you leap
It’s the advice we give people diving into a murky lake for the first time.  Is it shallow?  Are there rocks just below the surface?  Enterprise systems can indeed bring complex data elements into one place where decisions based on that data can be more effective and the benefits of those decisions can make a profound difference to an organization.  But you need to do your homework to ensure that you are operating your enterprise system in a way that you can get the benefits you need without exposing your organization to costs and risks that can quickly wipe out the value of those benefits.