Clarity

A question for those of you who have rolled out Clarity within organisations that do not have any project management tools in place. In other words, Clarity is the first PM tool that has been used.

I'm wondering about the prerequisites that are required from a project management maturity point of view that are required to have the organisation use it successfully. Is there a list of items that people can suggest? For example, rolling Clarity out in an organisation that does not have a PM methodology is probably a mistake because the configuration of Clarity depends upon a development process to be in place.

In addition, assuming an organisation with three country locations, what level of technical and business support would people recommend? Given that fact that users are both new to project management and new to Clarity, assistance cannot only be at a technical level but probably needs to be at a PM level as well.

Finally, for those people who have rolled it out, both successfully and not successfully, I'd be interested in hearing about really good things you did that worked well and stuff you'd do differently if you had to do it all over again.

Hi

What level of detail is desired to be captured on Clarity ? If it is just the basic level like baseline / resources / simple budget etc., then the best thing would be to open the modules slowly to the users.... Clarity is s vast ocean, a big monster... :) ...

As you said that the users are new to project management, it would be better to keep it simple -

1. Define the tasks in the project - Clarity allows creation of templates (with pre-defined tasks), and the users can use the templates to create projects
It would be helpful, as you can create the tasks in the WBS, by following any of the methodologies, and when the project is created using that template, the entire work breakdown structure will be copied.

2. Assigning resources to projects - This depends on how you wanna take it up. Clarity allows, booking of roles (which can be replaced by resources). It also allows directly assigning resources to projects (which is what I would suggest, given the point that the users are new to the tool)

3. Allocating resources to tasks - This is quite simple, given the above 2 points are implemented.

4. Tracking of timesheet hours
Tracking the time on the project (what happens when the resource, assigned to a task in the project fills the timesheet in the task - then how / when / where would it appear on the project. This will give a bit better perspective of how Clarity works as a tool.

5. In case, you want to track finances at a basic level, you can use the 'Budget' page, which will give you an overview of what you can expect in terms of finances. It will allow you to fill in the start and end cost plan dates and amount, and the expected start and end benefit dates and amount, and will give you the NPV / ROI values

Hope this info helps .. :)


Regards
NJ

The first question that must be asked is 'Why'? Why are you rolling out Clarity? What do you hope to accomplish? What business need is it addressing? What value to you think you will get from Clarity? If the thought is "Clarity will fix our broken processes and make us more mature in Project Management", you are heading down a path of disappointment. Clarity will support your organization, but it will not fix bad or non-existant processes.

A few more questions:
1) What modules are you going to use?
2) if you are deploying to multiple sites, do they have common processes? common reports? languages? security concerns?
3) Are you already using timesheets? is the process well defined? Who approves?
4) if you are going to use MSP (Microsoft Project) with Clarity, does the staff 'really' know how MSP works?
5) is management going to be accessing data in Clarity? if so, what data and how often?
6) Do you have a budget for training? (This will be key for you)
7) What is managements expectation of Clarity?
8) What is your timeframe for the depoyment?
9) On-premise or On-demand?


I can go on, but I think you get the general idea.

Regards,
Michael Thibault

Michael brings up really good points.

You really need to understand what you are trying to accomplish from a business perspective and ensure you have at least basic processes outlined. Now, those processes don't need to be set in stone, but you have to start somewhere. You will also need to define what standards are going to be - and sometimes that is no small feat.

From a support aspect, my old company has an international deployement of Clarity. The servers are based in the US, but outlying offices all tunnel into the same database. My first suggestion to everyone is that you create a helpdesk structure. We staffed this with Clarity SME's that can not only handle functional and tehcnical tool questions, but also have a PM background in order to be able to coach end users more effectively.

We also found it effective if there was at least one or two local 'champion(s)' for the tool that had additional training provided by the core group so they could help end users locally. This setup, in conjunction with providing end user training on a regular basis, is very effective. The thing that you really need to ensure is that you have the Sr. Management support for the use of the tool in all locations. If you don't have that, you will run into issues with end user adoption the further you get away from your base location.

Hope this helps,

Ruthann

Ruthann,

Thanks for the feedback, most of the comments are inline with my thinking and what I've heard from some "Clarity" experts.

I was interested in your support feedback, in terms of the number of people supporting the application. We have about 2,000 people in the company, most in either Australia, the US and India. My thinking is that we need a Clarity Application Manager to be full time responsible for the application's use and extension. Someone who is responsible for getting patches installed, collecting and analyzing user feedback and creating development plans for new functionality. I'm thinking we also need one "champion" in each country where 50% of their time goes in helping people use the tool to effectively manage projects.

What's your thoughts on my support suggestions?

I'm also thinking about the types of projects we run and there are some differences between them that would need to be reflected in Clarity. For example, one dept has a PM methodology different from another dept, for good reason. We would need to configure Clarity so the projects looked different for each group, yet rolled up "properly" to global reporting for senior executives. I know this is a common occurance in organisations but I have no idea whether one instance of Clarity can be configured for two different types of projects, with potentially different stages, etc.

Again, any thoughts or insights you can provide?