If you're like me (and I'm sure you are on this count), you're chomping at the bit to get your hands on version 4.8. Hang on, it's coming.

In the meantime, here's a preview of some changes you'll notice in version 4.8's Edit Task Information page.

1. The Assignment tab disappears

That's right! No more navigation required to assign users to your task. You'll have an «Assignment» group right underneath the Details field for that. When creating a new task, the assignment grid will be displayed. Otherwise, it will be hidden by default and the «Show the Assignment Grid» toggle will allow you to reach the grid in order to make changes therein.

2. Smartphone support for the Details and Comment fields

If you're a smartphone user, you've noticed that your device does not recognize both of these fields as text boxes. We've come up with a solution which will now allow you to input data in both of these fields.

3. Estimates and Actuals

Many of you have requested extra date fields in order to be able to monitor actuals and compare them to estimates more easily. AceProject 4.8 will introduce two new groups: the Estimates and Actuals groups. Viewing financial information will be restricted to users having the necessary rights. The Edit Project Information page will contain these groups as well, allowing Project Managers to have a global picture of project performance.

On another note, Ace will now allow you to specify, for each task, whether or not weekends will be considered working days.

Stay tuned for more sneak peeks in the upcoming weeks.

Connect with Michel Deslandes and the AceProject team via Facebook, LinkedIn and Twitter.

Sub-tasks are definitely one of the most requested features to add in AceProject. We are still unsure as to whether they will be added someday or not. There are technical reasons, but also usability reasons. Actually, sub-tasks wouldn't be used by everyone, and most users who would, don't need all the sub-tasking properties available in products like Microsoft Project. Our biggest challenge is to keep sub-tasks as simple as possible, and usable by anyone.

That being said, there's a workaround for sub-tasks in AceProject that works for many users. It simulates sub-tasks, although it doesn't replace them per se.

All you need to do is use integer task numbers for tasks and decimal task numbers for sub-tasks. If necessary, you may set dependencies between specific tasks. 

Here's an example:

We are aware that this is not ideal, but it works pretty well for basic sub-tasking.

Connect with Sylvain Traversy and the AceProject team via Facebook, LinkedIn and Twitter. 

A new default skin will be introducted in our next version (4.8). All users who are currently set with the "Classic Blue" skin (the default right now) will see the new skin as soon as they get upgraded.

Michel, our graphic designer, has been working hard on that skin for quite a while. The skin is still under development, but should pretty much look like this:

The header tabs look more modern, as they have no rounded corners. We also added a touch of our logo to the skin. Actually, Michel decided to use the circled arrow's red for the "Print the Main Page" button.

Furthermore, the skin uses our upcoming new website's colors.

Feedback is always appreciated! 

Connect with Sylvain Traversy and the AceProject team via Facebook, LinkedIn and Twitter. 

By Cameron Watson, QAIassist

Context

From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software.

A number of lifecycles have been developed to address specific disciplines within IT – examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC). In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables.

Software Development Lifecycle (SDLC)

The SDLC is used by application development and support teams to develop and maintain computer applications and systems. It is used across an organization and is applied from the inception of a through a successful implementation of the required solution. Though a multitude of SDLC’s exist, the majority of them rely a phased approach, pre-defined deliverables, and standard naming conventions. It will execute in parallel and concurrently with a software testing lifecycle (STLC). The following provides an overview and explanation of the sequenced phases of a generic software development lifecycle (SDLC).

Systems Analysis

The Systems Analysis phase is the first phase to be performed within an SDLC. It is initiated only and in conjunction with a project being authorized or approved. Its purpose is to ensure the requirements to satisfy a business need have been identified and translated into a notational form or models. Once documented, project teams (business and technical staff) utilize the requirements to ensure a common understanding is achieved and to verify the requirements are attainable. As an iterative process, the Systems Analysis phase ensures the project team members are working together to define and clarify the business need and promoting alternatives that could be utilized to address the business need.

Design

The Design phase ensures the application is designed according to the authorized requirements generated during the Systems Analysis phase. The Design phase focuses on the refinement and further granularity of the data, application and technology models defined in the Systems Analysis phase and incorporates other factors that must be considered in designing the solution (e.g. data and non-functional requirements, testing strategy). The solution designed is refined to a level (ie functional specification) where individual software, hardware and data components are defined and documented. When this phase is complete, it will be possible to generate comprehensive time and resource estimates for delivering the application and the necessary business functionality.

Build

The Build phase ensures the following:

1. The application is being built in accordance with the business requirements that were prepared and refined during the Systems Analysis phase
2. The technical and functional standards, as well as design elements of the business solution prepared during the Design phase are used as the basis for developing and testing the product.

The aim of the Build phase is to produce readable, testable and maintainable code for the application in a non-production environment.

Test

The Test phase ensures:

1. The technical code created during the Build phase adheres to the business requirements that were developed and evolved since the beginning of the project
2. The technical code adheres to the design standards prepared during the Design phase.

The aim is to ensure the code built in a non-production environment is viable and can be tested by the end users to assess its ability to satisfy the business need.

Release

The Release phase ensures the application has been satisfactorily tested and satisfies the business need. Once satisfying these criteria the application can be placed into the production environment and utilized by the user community in a production environment.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software.

A number of lifecycles have been developed to address specific disciplines within IT – examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC). In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables.

Project Management Lifecycle (PMLC)

The project management life cycle (PMLC) is used to initiate, plan, oversee and deliver IT applications and systems from inception to fully operational in a production environment. It is used across an organization and is applied from the beginning of a project (development or maintenance) through a successful implementation of the required solution. Though a multitude of PMLC’s exist, they commonly rely on and are executed using a “phased” approach, pre-defined deliverables, and standard naming conventions. The project management lifecycle (PMLC) traditionally acts to guide the software development lifecycle (SDLC) and the software testing lifecycle (SDLC).

The following provides an overview and explanation of the sequenced phases of a generic project management lifecycle (PMLC).

Initiate

Initiate is the first phase to be performed within the project management lifecycle (PMLC). It is the process of formally recognizing that a project exists and has been authorized to continue. The purpose of this phase is twofold :

• First, to assess and determine a business need.
• Second, to translate high-level business requirements into a set of requirements from which the project team will build the product and confirm the requirements can be fulfilled.

This iterative process is lead by the project manager who requires input and expertise from both business and technical IT resources assigned to the project.

Plan

The Plan phase is executed upon the authorization of a project. It is an iterative process used by a project manager to devise, maintain and execute a workable plan to ensure the business solution is effectively implemented. The workable plan must address:

• Project scope
• Resource requirements, project team roles
• Deliverables to be prepared throughout the project
• A schedule to define how and when the project will be completed
• The activities to be applied to ensure quality is incorporated into the implemented solution

Execute and Control

The Execute & Control phase is an iterative process that aims at coordinating the activities of the project team resources to ensure the project can be completed according to the project plan. The progress of the project activities are monitored against the project plan, and the appropriate corrective action are taken when the project is deviating from project plan. The Project Manager prepares and utilizes a number of specific deliverables to ensure project procedures are available to the project team, the project management deliverables are maintained throughout the life of the project, deviations to scope, schedule and resources are addressed in a timely fashion.

Closure

Closure is the final phase of the project management lifecycle. Its purpose is to document a true reflection of how the project evolved from start date through to its completion so that future projects can benefit from the knowledge and experience gained on the project. Future project teams can then leverage this knowledge to increase the efficiencies on delivering business solutions to their clients.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Although I have worked and consulted with a multitude of organizations throughout my career, I am always intrigued at how many varied understandings and opinions there are for the term deliverable.  In some organizations the term deliverable doesn’t even exist. In other organizations, it is relied upon to build and maintain every product and application.

Here’s my take on the concept: A deliverable is a tangible, quantifiable and measureable package of work.  

• Each deliverable has a specific purpose and context.
• It is a unique component, along with other deliverables, of a lifecycle/methodology.
• It supports and is referenced by other deliverables of the lifecycle/methodology.
• It has pre-defined requirements.
• It is created based on the unique characteristics of a product or project.
• Its information acts as the basis for maintaining a product or project.
• It can be verified, reviewed and approved on its own merit. 

The following principles are applicable to deliverables 

Cohesion/Integrity - Each deliverable acts as a building block to establish and bolster additional information needed as the product or project evolves.

Pre-established Informational Needs – the purpose for each deliverable is unique as is the informational requirements to complete it.

Scalability – the deliverables and the information used to populate them must be scalable to the characteristics of each specific project.

Creation/Review/Approval – each deliverable is prepared based on the required informational needs. The deliverable can be created, reviewed and approved based on its own merit.

Project Planning/Oversight – due to each deliverable having pre-defined and finite informational requirements, they can be incorporated as a measureable and quantifiable piece of work to be defined as part of a project plan and reflected on a project schedule.  Project oversight can be maintained by assessing the status and completion of the deliverables as they are created, reviewed, and approved. 

Applying a deliverable-based lifecycle/methodology provides an organization the ability to leverage a standard process that can be applied by all project teams to develop and maintain applications. Project managers can then  focus on delivery rather than  micro-managing the activities a project team member  is to perform to complete those deliverables.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

I was invited out to lunch last week by an old friend and colleague. We had worked at the same organization many years ago and had stayed in touch throughout the years. Once seated and our meals ordered, he broke the news. He had recently accepted a senior management position at a reputed fortune 500 company’ His role would be to guide the project managed office (PMO) for the company.

After receiving my congratulations, a somber and concerned look came over his face – he stated “I think I have just made a serious error with regard to my career.”

As we discussed things further I began to gain an appreciation for his statement.  He drew an analogy to a train wreck that gets replayed day after day after day – a perpetual circle of point the finger and lay the blame – without a beginning and without an end.

He began citing a number of instances.

• The users were in a constant state of wondering why changes to existing applications took so long.
• The IT application maintenance staff did not have any documentation to scope or verify changes being made.
• The development staff were creating applications in days without reviewing the development iterations with the user community.
• Testing (of any kind) was not performed on any of the applications being placed into the production environment.

As a result, the work environment became tainted with a “watch your behind,” “never trust a user”, “never trust a tech” mentality. Upon completing the description he looked at me with a bewildered look and said “what am I going to do ?”  I asked “what IT methodology is the organization using?” He responded “there is no recognized or formal IT methodology being used. Every project and maintenance team has their own approach and none of them are documented or communicated to the user community”.

I told him the more difficult the problem the simpler the solution must be.  I suggested that he could do one of two things.

1.       He could call his boss from his previous position and get his old job back;

2.       He could accept his new organization for what it was and make an effort to turn things around and point it in the right direction.

He acknowledged my point and we started down another tangent talking about what could be done at his new position to remedy the situation. He told me “the floor is mine” and asked for suggestions on how I would address things. I said that my most immediate concern would be the poor communication between the various departments and staff in the organization. Poor internal communications is often the root cause for a culture of finger pointing and lack of accountability. Then, I mentioned that the lack of formal IT methodology appeared to be the most significant deficiency within the organization.

Although many people subscribe to the notion that an IT methodology is used to consistently deliver quality applications in a timely manner, it can also provide additional benefits to an organization. More specifically, it would

• Provide a common tool and language that organizational staff (business and IT) can utilize for developing and maintaining applications;
• Create a framework that organizational resources could leverage to perform project management, software development & maintenance, and software testing;
• Establish a deliverable-based and scalable process to address a multitude of IT projects to ensure organizational resources could be proficient on a multitude of applications in a multitude of environments.

As we left the eatery he thanked me for getting out to lunch with him and was appreciative that I was able to toss my two cents into the discussion. I then asked him if he was going to call his old boss back. He smiled with a glint in his eye and said, “no way – there is an organization that has to be saved and I’ve got to start that effort this very afternoon.”

Suffice it to say, I am looking forward to getting back out to lunch with him in a month or so. I am interested to hear how his effort is going and hoping to be able to add another two cents. I’ll keep you posted.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

One of the questions I am asked most frequently is “What is the most important deliverable of an IT methodology”?

The simplest answer is “it depends”. The more appropriate answer is “it depends on the scope of the project, whether a project team has been assembled, whether the project has been approved, if user requirements have been defined, what the technical alternatives are, when the project has to be completed, if the business users have been trained, etc, etc, etc”.

Every project is different. Every project stakeholder is different. Every project team is different. Every deadline is different. The uniqueness and dynamics of these ever changing variables ensures the “deliverable” deemed “most important” will change as the project and project team evolves. When I am faced with this question I usually try and respond with a story about Snow White and the Seven Dwarfs.

Stew Anyone

Once upon a time Snow White had invited all of the dwarfs over to her place for dinner. The first thing to meet the dwarfs upon their arrival was the smell emanating from the kitchen – its aroma was delightful and they kept asking Snow White what was for dinner. After some coaxing Snow White revealed that she had made up a pot of stew.

The Dwarfs conceded that they did not know what stew was and wanted Snow White to tell them what the ingredients were. Snow White relented and said “my stew is made up of a number of things – roast beef, potatoes, carrots, yams, peas, barley, celery.” Snow White then invited the Dwarfs into the kitchen to look into the pot as the stew simmered. The Dwarfs were so excited to see the stew and each of them kept telling Snow White they could not wait to try it. They all promised they would eat all of their stew.

After viewing/smelling the stew, Snow White told the Dwarfs to find their seats at the dining room table she had set and she would bring the stew out for everyone to enjoy. The Dwarfs gleefully found their spots at the table and were eagerly awaiting Snow White to arrive from the kitchen. Snow White entered the dining with a huge bowl of stew and told the dwarfs to help themselves to a serving while she went back to the kitchen to get the salad, the buns and to make sure she had turned off the oven.

Upon her return to the dining room, Snow White was pleased to see the hungry dwarfs devouring their dinner and asked if they were enjoying the stew. Their collective response was a resounding “yes!” In hearing this praise, Snow White sat down at her place at the table to recognize a most disconcerting reality - Sleepy had only the roast beef on his plate, Dopey had only the potatoes on his plate, Sneezy had only the carrots on his plate, Happy had only the yams on his plate, Grumpy had all only the peas on his plate, Bashful had only the barley on his plate, and Doc had only the celery on his plate.

Upset, Snow White confronted the Dwarfs saying: “Why did you separate all of the ingredients in the stew?” Each of the Dwarfs responded with the same answer: “We each knew what we liked and knew we would enjoy our own if we separated the ingredients.”

Snow White got up from the table, went back to the kitchen and returned with another large bowl of stew. This time she served the Dwarfs herself – each receiving a plate full of all the ingredients. After a little encouragement each of the Dwarfs tried the new concoction – with every mouthful the smiles on their faces got broader and broader. The Dwarfs had come to realize that the combination of all the ingredients was the secret to success.

Moral of the Story

Although an IT methodology is made up of specific and unique deliverables, its true value is best realized when the all deliverables are used together throughout the life of the project. An authorized User Acceptance Test Authorization deliverable utilized at the completion of a project is no more or less important than the Project Charter that was created to initiate the same project.

Bon Appetit!

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

The project charter has been around for as long as the concept of work.

The Egyptians used project charters to create the Pyramids. So did the Greeks to erect the Parthenon. Even the Romans used a project charter to create the Coliseum. Little Johnny used a project charter to construct his miniature house made of lego blocks.

As different as the times and methods used to create these structures were, one common thread exists - success was based on the creation, maintenance and oversight of a project charter. The Egyptians may have created theirs with hieroglyphics in the sand, the Greeks may have chiseled theirs in Mount Olympus, the Romans may have penned theirs in Latin, and little Johnny may have used crayola on the kitchen table. The point is not how complex or sophisticated the project charter was, but rather, that one was required, prepared and relied upon to act as a foundation to create all of these structures.

While academia can spend days crafting a definition of the complexities and internal dynamics of a project charter, anyone can define it in five simple words: "what are we trying to do?"

Though the term project charter is routinely applied and recognized within the Information Technology (IT) industry, the concept of project charter is as applicable to organizational strategic planning, corporate budgeting and operational oversight. It is difficult to fathom a corporate president  or  CEO performing their roles without defining and documenting "what are we trying to do?" or a CFO maintaining fiscal control without defining and documenting "what are we trying to do?"

The concept of "what are we trying to do?" permeates every facet of every organization. Suffice it to say, the tenure of a CEO would not be very long if they were unable to articulate and gain approval of "what are we trying to do?" from the shareholders.

On the surface, addressing the project charter "what are we trying to do?" question appears to be a simple exercise, be it a CEO, CFO or an IT Project Manager. In reality, it can become a  very trying and taxing exercise. The amount of definition and explanation required in a project charter depends upon the magnitude and complexity of the "what are we trying to do?" question. A project charter used to document how one person should dig a hole in the ground could be documented on half a sheet of paper, while a project charter used to document how to send a space craft to the moon and back would span  many pages. 

The utilization of a project charter is as varied as the number of organizations that create and apply them. In some cases the project charter is the project’s bible and is relied upon throughout the project. In others cases, the project charter is a project title and a brief project description. The project charter has been adapted and customized by organizations to address a myriad of needs. Here are a few contexts where the project charter is used.

Corporate - Project Definition
As an initial project document, the project charter establishes the goal posts from which the project will be initiated, planned, pursued and completed.  The project’s definition will reflect its size and complexity. It can include the following:

• The purpose of the project
• The scope
• The objectives
• The resources (HR and otherwise) to be utilized on the project
• The plan
• The cost estimate
• Project hierarchy and organization
• Risks and impacts the project will have on the organization.

 The project charter is not a stagnate document, it evolves and is maintained to reflect the changing circumstances and conditions associated with the project. The project charter acts to establish the project context and boundaries to ensure all project team stakeholders and resources have a common point of reference and understanding of the project throughout its duration.

Corporate - Project Authorization
The project charter gives organizational stakeholders the ability to review and evaluate priorities. Utilizing the project charter to obtain formal authorization ensures there is a correlation between the corporate strategy, planning and budgeting exercises and the organizational resources allocated to complete a project. This ensures organizational resources will remained focused on the authorized projects.

Corporate - Project Scope Management
After establishing the project context and boundaries and receiving formal authorization, the project charter can be used to monitor and evaluate the scope of the project from beginning to end. Project stakeholders are able to reference the project charter to monitor the project progress and direction in relation to the original context and boundaries they had originally approved. This affords project stakeholders the flexibility to stop, defer or accelerate IT project team priorities to better reflect organizational business needs. It also enables IT project team resources the ability to re-calibrate their efforts based on decisions and approvals of organizational stakeholders. 

Corporate - Formal Deliverable
The project charter establishes an operational premise to promote structure and formal documentation. This is very important to the efficiency of IT delivery and support. This concept of structure and documentation can be leveraged by the organization to introduce quality assurance and to improve the maintenance and support of  applications.

Project  - Planning & Oversight Benchmark
Once authorized, the project charter can act as the basis for a project planning exercise. The Project Manager is able to reference the original definitions established and authorized in the project charter to provide greater clarity and detail on how the project will be executed. Project plans, project schedules, project resources, project budget allocations are derived from the authorized project charter.

Project - Team Communication
The authorized project charter provides the mechanism the project team will rely on throughout the life of the project. It acts as the basis for the deliverables and wok products identified in the project plan and project schedule. Having formal documentation prepared provides several benefits. Project development teams will have access to the necessary information to ensure project team communication is consistent and based on formal approvals - all project development team members can rely on the authorized deliverables to ensure they are working off the same page. Application support and maintenance teams have a common point of reference they can leverage to effectively maintain and incorporate new functionality into the applications.

Wrap Up
Although the concept and need to create a project charter has meant different things in different environments for different audiences, its primary purpose has remained the same. Be it the Egyptians or Little Johnny, as long as the concept of work exists, we will need to know "what are we trying to do?"

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

It's that time of year again: most of us are getting ready to a well-deserved break from projects and business.

On behalf of the whole team, I would like to give you my warmest wishes for the holiday season and the coming year.

Yes, we're taking a break too!

We would like to inform you that the AceProject team is taking a break during the holidays. Our offices will be closed from December 24nd, reopening January 5th.

If you encounter an emergency during this period, please send an email support@aceproject.com. We will keep an eye on our inbox during that period.

Note that our servers will remain online during this period. There will be no interruption of service for Hosted accounts.

Thank you for using AceProject

AceProject would not be the success it is today without you. We would like to thank you for using AceProject.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Software bugs by FlapJack

Last week we held our Q&A webinars. The idea was simple: we wanted to answer everyone's questions about AceProject. Also, we had put together a little surprise for our attendees: screen shots of the upcoming cost tracking features.

The first webinar went well and people we really happy with it! We were delighted at were looking forward to the second one.

And that's when technology happened.

As people were logging in the second webinar, we lost audio. Not just some attendees. Audio was down for everyone. It was bad enough that after 15 minutes, I gave up an rescheduled the webinar for this week (December 16, 2pm EST). I felt awful about having to strand everyone who showed up to get their questions answered. After all 60+ people showed up for the webinar, and I couldn't get it to work!

I was pleasantly surprised to see how supportive the messages were during my failed troubleshooting. People told me not to worry about, that technology happens, and that they were not holding it against me.

What's the lesson here?

1. We can't control everything.
2. People deserve more credit than we give them when it comes to technical problems.
3. Acknowledging a problem and apologizing for the inconvenience is a simple and effective way to deal with the uncontrollable.

What about you? How do you deal with the uncontrollable?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Recurring tasks is one of the most requested features on our wishlist. Since this feature is rather complex to implement, and we have a lot on our plate, we have decided at this time to invest our energy on other enhancements like cost tracking. Recurring tasks will be added to AceProject someday, but not in the near future.

That being said, there is actually a workaround for creating recurring tasks in AceProject, thanks to the "Move/copy a task" feature. If you're willing to repeat the process periodically, you'll get recurring tasks without too much trouble. Here's how to:

Step 1 - Open the task that reoccurs and click the "Move/Copy" link at the upper right.

Step 2 - Select the "Copy this task within the same project" option.

* You may also select items to copy (comments, task documents and/or user assignments.)

* When you're done, click the "Go to Step 2" button.

Step 3 - Set the new task's dates (i.e. the next occurrence)

Step 4 - Repeat

* As I mentioned earlier, I suggest you repeat this process periodically. It's more convenient to create recurring tasks in bulk than every once in a while. Here are the frequencies I suggest (depending on your needs and free time): 

• Weekly, monthly or yearly for daily tasks
• Monthly or yearly for weekly tasks
• Yearly for monthly tasks

Connect with Sylvain Traversy and the AceProject team via Facebook, LinkedIn and Twitter.

Change by David Reece

Last week I had the pleasure of attending a conference on leadership. The part that stuck with me was about change management and mourning.

We tend to see resistance to change as stubbornness. Sometimes we even see it as bad faith. People who resist change (and we've all been there) have very bad press. Maybe we would gain from trying to understand resistance to change?

In order to start something new, we must give up the old. We are attached to our old ways. Giving them up, in a way, includes a mourning component. Maybe, if we give ourselves time to accept that the old ways are not longer viable, it will be easier to welcome the change?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Next week, I'll be hosting Q&A webinars. This is the perfect moment for you to ask any any question you've ever had about AceProject!

The webinar is not a sales pitch or a scripted demo. It's a simple chat with between our users and us, about our project management system.

For one hour, you can ask any question you want about AceProject.

• Clarify how features work
• Give feedback on the application
• Ask about future development

Register for the webinar here:

• Wednesday December 9 2009, 9am Eastern Time
• Wednesday December 9 2009, 2pm Eastern Time

There is also a webinar in French on December 10, 2009 at 9h30 Eastern Time.

I look forward to chatting with you and answering all your questions!

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

By Cameron Watson, QAIassist

I was sitting in the park last week and my mind began to reflect on how the IT industry has evolved over the past 50 years. What once was loading registers in binary code into a computer the size of a room has evolved into everything from worldwide communications to interactive games to artificial intelligence (and everything in between) - and all at the speed of light.  Suffice it to say the world has changed and the world will continue to change. The card readers and weekly batch reports have been replaced with ever evolving technology and gadgetry.

As the children laughed and played on the swings and ladders my mind began to drift into the varying technologies I have had the opportunity to witness. I have to admit we should tip our collective hats to COBOL - still alive and kicking. Between the kids hoops and hollers, I came to a very basic understanding that there was a distinct difference between technology for the sake of technology and technology for the sake of business utility.

More and more, we hear "if something cannot prove it is contributing to the corporate bottom line, then it brings little value."

As I got up to go over to the ice cream booth, it hit me. The little light bulb when on. "No wonder business stakeholders are beginning to understand, contemplate, and even leverage the whole IT "outsourcing" delivery model. They are coming to believe its potential and trust it can contribute to the bottom line.

As market conditions force organizations into achieving greater degrees of operational efficiency, additional expectations are being placed on IT to deliver products/services in a timely, cost-effective and consistent manner. Successful organizations have already recognized the correlation between increases in operational and IT efficiency and the process/methodology they are applying.

As I started to indulge (butter pecan - it was perfect) I realized that business stakeholders are evaluating the ROI of their IT budget and looking to optimize operational performance. One option is to increase internal IT efficiency via process, metrics and methodology. The other option is to utilize the IT outsourcing model. Though the operational impact of these alternatives is significant, the intent is the same - to obtain more effective business solutions at a much lower price - IT "value" is the bottom line.

By the time I got to the cone (ice cream all but gone), I had recognized that outsourcing vendors can not only provide estimates and costs for project development and maintenance, they can also include metrics and measurement performance benchmarks into formal contracts. Many business stakeholders are surprised that the outsourcing vendors can commit to these promises and do not understand why they can’t get them from their own IT staff.

Cone now gone and a drop or two on my shirt, I realized many business stakeholders are faced with evaluating IT ROI scenarios.  As outsourcing vendors continue to deliver and penetrate the IT market they are quietly and frequently proving they can deliver on their claims. The outsourcing model, once perceived to be fraught with danger and risk, is now turning into an acceptable and routine approach business stakeholders are leveraging to obtain greater IT value.

As I got up from the bench I tried to understand why and how outsourcing vendors could continue to perform so well in IT markets. My initial perspective was that they have recognized the fundamentals of method-based approaches: 

• a methodology must exist and be applied to create any product or deliver any service;
• a methodology must exist and act as the basis to establish, obtain and assess metric and measurement information;
• methodology metrics can be used to justify IT service and delivery ROI value;
• if IT ROI value cannot be quantified, business stakeholders will pursue alternative approaches

Tired from all of the thinking, I got in the car to leave the park. I turned on the ignition and on came the radio, down went the automated windows, on came the onboard computer with the voice communication to tell me the route I should take to go home. Ah, technology. Though a beautiful thing, its continued evolution dependent on its ability to deliver ROI to business stakeholders.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

I am very pleased to have the opportunity to share my knowledge and experience with the readers of the AceProject blog. I want to say thanks to AceProject (and Karine Simard) for granting me this opportunity. My intent in writing is to help the various audiences and users of IT methodology obtain a more in depth knowledge of how IT methodologies (project management, software development, software testing) can be utilized and leveraged to contribute to increasing IT efficiency, operational performance and organizational bottom line.

The ancient Greeks first coined the term "methodos" - its definition meaning "path". They applied this term in various contexts - as a noun "a path that could be followed to reach a destination" and a verb "the journey to be taken along a path". Though several millennia have passed since the ancient Greeks first used the term, it is still applicable in today's world of Information Technology (IT) - it’s called "IT Methodology".

As simple as the term IT Methodology may appear, it is intriguing to see how it can be applied in such a variety of contexts, by such a wide array of experts, to such a diversified set of audiences. Suffice it to say, this lack of clarity and context has introduced its own share of confusion, misunderstanding, miscommunication and misadventure. 

Let’s provide a context around the term "IT Methodology"

IT Methodology – the road you take

As a noun, "methodos" can be equated to a road on a map. For example, the highway that connects Boston to New York. It has a beginning and an end. It is tangible. It has a predefined set of destinations that must be passed along the way, such as a city, a town, a river, a crossroads, etc. The road is constant and indifferent to how many vehicles use it, what vehicle is to be used, how many people are in each vehicle, how fast each vehicle travels or how many times the vehicle starts and stops during its journey.

As a noun, "IT methodology" is much the same as the road. It has a beginning and an end. It has a pre-defined set of criteria that must be passed along the way:  lifecycles, phases, deliverables, work products, etc. It is consistent and indifferent to how many projects utilize it, the scope of each of the projects, the size of the project team, the speed at which a project team completes it, the number of iterations a project team employs. Examples include ITIL, Rational Unified Process (RUP), CoBit, and QAIassist Integrated Methodology.

IT Methodology - how you travel that road

As a verb, "methodos" describes how the road will be used. Travelers using the road between Boston and New York have the option to travel in the vehicle of their choice at the speed they wish, and to make as many stops as they wish along the way.

As a verb, "IT Methodology" is the delivery approach a project team takes to get to its destination, a completed project.  Examples of delivery approaches include Waterfall, Spiral, Rapid Application Development (RAD), Agile, Joint Application Development (JAD), and Scrum.

IT’s not all Greek

Though the effort to understand the term "IT methodology" may appear to be long, winding and Greek to many, there is a difference between the “road” used to get to the destination and the “activities” that will be performed while on the road and heading to the destination.

While most people will agree that it’s important to agree on the goal of a project, we tend to forget that agreeing on how we will achieve that goal is just as important.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

There is a lot about control in project management books and best practices: we need to control scope, budget, schedules, quality, etc.

It's expected of project managers that we have control over the project. But what about the uncontrollable? What about people?

People are not as easy to plan around as machines or supplies. When we put a printer on a table, we don't expect it to call in sick or start printing badly because it's having troubles at home.

But people do.

Our developer Pascal is very important to our team. He's the main developer for AceProject. When he's not around cranking out awesome features, AceProject development slows down noticeably. Yesterday, Pascal's girlfriend was hospitalized as a result of getting the A H1N1 flu. When we heard the news, no one thought about Pascal being absent of a few days, or the impact it would have on his projects. We were all worried for him and his family.

There is nothing any of us can do to help Pascal, and his absence will impact his projects. I hadn't realized how it would affect the whole team here. And this cannot be controlled either.

How much control do we really have on our projects?

I think we have as much control as our team gives us, as long as luck is on our side.

What do you think?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

I am very happy to introduce Method Thursdays at Go Ahead, Manage. Every Thursday, we will have a guest post by Cameron Watson, from QAIassist. Cameron is an expert when it comes to project management methodologies. I was very happy when he accepted to post weekly here!

First and foremost, here is a short interview I did with Cameron this week:

Tell us a little bit about yourself
My name is Cameron Watson.  I spent my early years growing up in a small town near Ottawa, Ontario. After graduating from college (over 25 years ago) I began my IT career as an IT printing operator with a service bureau in Toronto. After several years I was offered an opportunity to try my hand at programming a simple costing application written in Lotus123. This opportunity was the seed that got me started along the road of information technology (IT).

During my first decade in IT, I followed a traditional career development path: programmer, analyst, team lead, project manager. The past 15 years has been a steady progression of applying this expertise in the disciplines of organizational process improvement, project managed office, and organizational change initiatives for a number of large organizations such as Boeing Aeroplane, OAO Technologies, and Aviva Insurance.

In 2006 I began translating the lessons I had learned while attending the school of hard knocks into a company called QAIassist. Since start-up, we have helped organizations increase and optimize their IT delivery and support efficiency. Our flagship product, our Integrated Methodology, incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget.

Away from the office, I enjoy the outdoors and wildlife, getting out for a slow drive on the back-roads, hitting a little white ball around a field, and sharing discussion and company with good friends and family.

How did you develop an interest in project management? 

My initial interest in project management was more a result of fear than of wanting to learn.

It was sink or swim time for me – either grasp the concept of project management and contribute to the team or look for another career. My primary interest was on ensuring I kept my job, and the only way that was going to happen was if I was able to learn the principles and tools of the project management discipline.

My first programming assignments were a true baptism of reality. I remember my early undisciplined approach: build some code, test it, build some more code, test it. This eventually evolved into having a well defined schedule, predefined set of deliverables, roles and responsibilities, change log, etc that were used to plan, control and guide the project team.

Suffice it to say I was able to retain my job. Since the fright of these early programming days, I have come to appreciate the significance of project management, the tools required to apply it, and the positive contribution it can have on delivering product, operational performance and bottom line.

And how did you get interested in project management methodology specifically?
While working at The Bank of Canada I had the good fortune of working on a large project team of about 60  resources. We were responsible for developing an elaborate and complex application that would administer Canada’s domestic market debt. At the same time, the Banks Information Technology Department was in the process of implementing DMR’s P+ Methodology, so we decided to apply this methodology on our project.

As the project evolved, it became apparent that its success would be based on how the project was managed. The seasoned project manager developed, communicated and leveraged the project management deliverables of the methodology throughout the life of the project – these deliverables kept the project team in sync and communicating on the same page. It was intriguing to watch the project manager use the project management methodology to successfully deliver the application on time and within budget.

Working through this project provided me a firsthand experience in knowing the significance of applying project management – without it the project may have failed.  It was this project that made me realize the success of any project could be traced to how effectively a project management methodology was applied.

In your opinion, what is the biggest challenge organizations face when implementing a project management methodology? 
Although most organizations rely on information technology (IT) to optimize operational efficiency and bottom line, they all apply varying degrees of project management.  A major challenge any organization faces is to recognize there is a direct correlation between the degree of project management they apply versus the productivity, product, and operational efficiency that can be delivered.

In some organizations, they recognize this correlation, effectively apply project management, and routinely deliver quality products and services on time and within budget. Other organizations are unaware of this correlation, do not apply focus on project management and remain in a constant state of wondering why the products and services they deliver are of inferior quality, late and over budget. 

The key is to ensure stakeholders are made aware of the benefits that can be derived by applying a project management discipline and providing them the support they require to better appreciate that project management will afford them a mechanism to

• implement a repeatable process to consistently deliver quality applications
• accurately define and control project scope, schedule and costs
• effectively monitor and communicate project progress within (business and IT staff) the project team
• deliver accurate status (schedule, risks, issues) to stakeholders
• apply organizational governance and quality assurance to application development and testing
• establish organizational metrics for ongoing improvement of application delivery and maintenance

What's the biggest methodology mistake you've made? How did you fix it?

The biggest methodology mistake I ever made was to assume if I worked less on creating and monitoring deliverables, it would save time and money as the project evolved. Although this decision saved some time and effort at the beginning of project, it soon became apparent that this lack of initial effort on the project management deliverables caused confusion. Project team members did not know their roles, the deliverables they were responsible for or which deliverables were on the critical path. The team was also unable to provide an accurate status to the project stakeholders, etc, etc etc. In a nutshell, chaos with a snowball effect.

After eating a generous helping of crow as the project floundered - and getting some advice from a senior project manager, I took a step backward and created a number of project management deliverables: project charter, project plan, project schedule, etc. Once these project management deliverables were created, the project team began to focus and started working together as a united team with a common purpose to deliver the project.  Suffice it to say, I learned a valuable lesson from this project. What sometimes seems to be a shortcut can lead you down a path that is longer, riskier and more costly (never mind the foul and lingering taste of the crow).

Next week: IT Methodology - A long and winding road

Find out more abour Cameron and QAIassit

Visit QAIassist's website and get in touch with Cameron!

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Today is International Project Management Day. I bet there will be quite a few posts on project management as a profession and a methodology.

I would like to talk about something that is to often forgotten in projects: the importance of the sponsor in the project.

No project without the sponsor

If no one wants the product or end results of the project, there will be no project. The sponsor is not only the initiator of the project, she is the reason for the project to exist. The sponsor is not just the flag-waver in the race to deliver the project on time and under budget. The sponsor must be involved with the project at many levels:

• At project kick-off. It's a communication issue that is too often glossed over: the project team should understand who is initiating the project, and why it's being done. This should be learned from the project sponsor directly. The project manager saying "the sponsor told me" just doesn't have the same value, or the same credibility for that matter.
• For all major changes to the project. It's up to the sponsor and the change control committee to decided on major scope, delays or budget changes in the project. Giving the project sponsor this visibility helps the project manager from developing image problems with the team.
• At major deliveries or milestones. Connecting the team with the sponsor at key project events such as deliveries helps the team and the sponsor understand each other, instead of constantly communicating through the project manager. 
• At project closure. It's up to the project sponsor to sign off on the project.

No authority without the sponsor either

I have seen the situation first hand, where the project manager was not supported by the sponsor publicly. Without the support of the sponsor, the project manager may not be perceived positively by the team, which will affect the project itself quite negatively.

As a project manager, I've learned to make sure that the project sponsor is involved in the projects, if only to communicate to the team what is required of them and of the project.

How do you deal with your projects' sponsors?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Nowadays, we hear more about wikis, blogs and tweets than forums. Actually, forums are not as "Web 2.0" as these collaboration tools. Nevertheless, discussion forums are incredibly useful in a project management application, from a collaboration standpoint. 

Everybody's talking about Twitter and how cool it is to post 140-character messages. I definitely agree with that. However, let's not forget that a forum enables you to post both short and long messages. With Twitter, if you have a lot to say, you'll have to post several short messages, which is not always convenient and interesting to read. A forum still remains the best of both worlds.

In AceProject, there's a comment thread at the task level and a discussion forum at the project level. Both empower involved users to share ideas, knowledge, tips or any other useful information. The discussion forum is more powerful however. In addition to general discussion, it permits creating topics. Messages are then posted in a specific topic and replies to these messages can be posted thereafter. Hence, collaboration capabilities using this feature abound. From building a knowledgebase to simulating a helpdesk, the discussion forum is much more than a simple conversation tool.

Here are a few practical examples of how the discussion forum can be used in a project:

• Build a knowledgebase that can be used for troubleshooting. Users can easily search for keywords using "Text-to-Search", which helps them find answers to their questions in a flash.
• Create a wishlist (gather customer requests, potential enhancements, etc.).
• Simulate a helpdesk system (allow customers to post messages when they encounter issues and have every issue handled by your support staff). Thanks to the email notification feature, the customer can get notified when their issue gets fixed.
• Use it as a blog (why not?)
• Discuss issues
• Share knowledge
• Build a FAQ
• And more...

Here's a video that highlights the discussion forum feature in AceProject.

Connect with Sylvain Traversy and the AceProject team via Facebook, LinkedIn and Twitter.

Webcom in Montreal today was a very stimulating conference. While the last one, in May, was all about being open (APIs, OpenID, etc), this one seems to be all about 2.0. The revolution in marketing, medias, products and doing business in the modern world.

In the spirit of the conference, I decided to use Google Wave to document the conferences I was going to attend during the day. A few participants  joined me in my documentation of the wave.  I’ve had a Google Wave account (and the envy of more than a few of my peers) for a few weeks now, but I hadn’t had a chance to really use it. 

With Webcom, everyone was taking notes and sharing their impressions of Webcom.  While I was more inclined to summarize what was being said, others we adding context and reference links. The result is a rather complete document of the talks. It was more than a wiki (no coding required) and it was more than simple collaboration (everyone is in the same document and types without affecting everyone else).

Here are some screenshots of what it looks like:

Anyway, back to Webcom

As I wrote earlier, the theme was definitely change. How social media is changing everything: how we do business, how we work together, how we market our products, how we manage our projects. Social media could very well be our generation’s quiet revolution.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

How about fitting a square peg in a round hole? Or attracting bees with vinegar?

With these examples, it's obvious that the wrong approach is used. It could be the wrong tool, the wrong strategy or  just the wrong idea.

Why do we keep doing it then?

We like our tools. Even if they don't work. We like them because we're used to them and we've learned to work around their shortcomings. Even when our tools have big problems, we tolerate them because at least we know what the problems are.

Alas, it comes a time where we must move on from our old, clunky, comfortable tools to shiny new ones.

Understand it's time for a change

Before we can start looking for a new tool, we should make the case against the old one.

• Focus on the pain points of the tool. Get a list of the tool's shortcomings, and explain them in a way that sounds as neutral as possible.
• Stay away from blaming the people using the tool. We must remember that people like familiarity and making them feel bad about a tool they like is not the best way to bring them over to our side.
• Look forward. By asking people what more they would like from a tool, we can focus them away from the past.

Selling the new tool

When changing from a broken tool to a new tool, selling it right is very important. Knowing our crowd is essential.

• Find a solution that fixes most (if not all) of the pain points. There has to be benefit to the new tool.
• Under promise, over deliver. Buy-in will be faster if the system is better than promised. Not the other way around.
• Involve the end users. Empowering people makes a big difference in getting them to accept the new tool.

After-sales service

Once the tool is in place, we have to keep selling it to our team. If team members feel abandoned when they have questions about the tool, they may start blaming the tool or even stop using it altogether. As the champion for the new tool, it's our responsibility to be there for the people we convinced to adopt it.

• Get feedback. Don't expect people to provide their unsolicited opinion about the tool. Ask for it, and ask for it frequently.
• Own up. If the tool has issues, acknowledge it.
• Fix it. Whatever problems arise should be addressed quickly.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

If we wear an ill-fitted shoe, there will be friction between our foot and the shoe. If left unchecked, this friction will turn into a painful blister. Afterward, we will be unwilling to wear the shoe again because of the pain that friction cause our poor foot.

The same process happens if there is friction in our projects. If friction prevents someone from doing their job on the project, they will associate these negative impressions with the project as a whole.

This is why we should work hard at removing friction and making things easy for the project team, internal and external.

It should be easy

• It should be easy for the stakeholder to request changes
• It should be easy to a member of your team to raise a flag about an issue with the project
• It should be easy to the sponsor to know how the project is going.
• It should be easy for everyone involved with the project to know what's the next step 

How easy are these things in your project?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

This week Josh from pmstudent.com contacted me to update a study help Excel sheet I built back when I was studying for my PMP exam. With the PMBOK update, the spreadsheet was obsolete.

As I was updating the processes, inputs and outputs, I noticed that while the processes themselves hadn't changed much, the inputs and outputs terminology has changed quite a bit - and for the better! For example, instead of listing all the management plans (human resources management plan, comminucations management plan, quality management plan, etc.), the PMBOK nos simply lists "project documents." A much simpler term.

I saw two new things in the inputs and outputs:

• Requirements traceability matrix. It's a table designed to link requirements with their origin, like a business need or a project objective.
• Stakeholder register. Similar to a risk register, it's a document where information about the stakeholders is kept. This is useful to make sure all stakeholders are involved in the project at the proper level.

Download the study helper: Excel 2000-2003   2007

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

We officially released the Source Code version of AceProject 4.7 today. The Hosted version was released several weeks ago, so we got plenty of time to fix issues we hadn't found during our testing process (thank you Hosted customers :-)). As a result, we're glad to offer a stable Source Code package.

Improvements in version 4.7 have been discussed quite a few times on this blog already. Now, here's a video presentation of those improvements.

http://www.youtube.com/watch?v=EiCpJzn2mo0

In most of the places where I've worked, the sales team was never seen positively. It seemed working in sales made you a worse person for it. 

It seems sales is seen as a manipulation effort to extract money from people, barely above theft.

It's time to adjust our perspectives, no?

I was once travelling with a sales rep and he told me "you know, sales is the team that goes and gets the money for your paycheck. It's great that I get to sell a product that works so well."  There is the symbiosis.  We need sales to develop relationships with our clients and we need a great product and great service to keep the client coming back.

Sales is really only pre-sales customer service.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

We've been working on AceProject 4.8's new cost tracking features.

Cost tracking has been an often-requested feature set for AceProject, and we're finally doing it!

While working on the cost tracking module, we realized that not everyone would want to track costs in AceProject. This is why we decided to give that flexibility to our users. While we were at it, we also added another requested feature: the ability to disable all time sheet features in AceProject. You will be able to do this via the Account Info page:

The nice thing about disabling time and cost tracking is that our clients will have the choice of either a very simple interface for project management, or a full-featured, iron-triangle project management system.

Keeping it simple is the challenge

We have worked for eight years to keep AceProject simple. Adding the cost-tracking features while keeping AceProject simple is a daunting challenge. While we need to have a complete feature set, we don't want to confuse anyone.

Each person (within their access rights) will enter their expenses in the My Office tab. 

Much like the time sheets, expenses can later be sent for approval to the project manager. Reports will be available in My Office and at the project level.

No, that's not all.

There will be more to come in the next weeks: setting a user's hourly rate, project cost VS estimates reports, managing over time costs, etc.

Please comment and let us know what you think.

AceProject 4.8 should be released in early 2010.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Earlier this week I posted a piece about keeping in mind that we are working with people, and as project managers we should not become obsessed with the processes and methodologies.

The post created such interesting discussions on Linkedin  I've decided to share some here:

• Paul McKelvey wrote:
  "Reward is another thing humans like. It may be cash, but it can be recognition. We call it the "psychic paycheck."  
• Peter Michaelson wrote: 
  "The team is a must for project success and the component of the team are the people. Each one has unique personalities that the project manager must understand and be able to work with." 
• Ajaya Gupta wrote:
  "Doing things right and the right way is a hallmark for success" 
• Ned Robins wrote:
  "Teams are like families. They grow. Good leaders are like good fathers. Occasionally they dish out a spanking. More often they give a little thanks and praise. But they ALWAYS care. A lot. About every member of the team. " 
• Maria Puntel wrote:
  "We can have the best tools, excellent processes in place, but without a good team you will not get the results you expect. The secret of having a good team is making people feel that they are needed, they play an important part in the project, we really care about their ideas or suggestions, and they are respected." 
• Peter Burg wrote:
  "The United States Air Force defines leadership as the art of influencing people to pursue a common goal. This article states that project management is about a group of people working together to achieve a common goal. My experience is that balancing management and leadership is quite a challenge." 
• Marsha Pourmand wrote:
  "Project management is the process of following the process and established guidelines by the team and Project Manager and line managers, etc... to accomplish the stated objectives, including managing the resources and people. In my opinion it is a process first, maintained and measured and adjusted by people!" 
• Tom Magee wrote:
  "Candy and coffee arte great project management tools. " 
• Jun Bucao wrote:
  "It's about the processes created by humans. Taking care of both helps. Select the right 'humans' to create the right processes is great. It's when you have the wrong 'humans' creating the processes or the right 'humans' creating the wrong processes" 
• Jim Lacey wrote:
  "Managing projects requires holistic orchestration of all available resources." 
• Pjotr Myakoshin wrote:
  "It does not matter what framework you are using - Agile, PMP, etc. There is one simple rule - it is not you, who is doing the project - it is project team. Without them - you (we! :) ) are just a lonely person with responsibility to deliver... " 
• Alan Sim wrote:
  "I think PM is about making processes work for humans. Standard processes will not work because each human is different and the team is comprised of many different humans working in different & changing environment. We have to constantly make fine adjustments to the processes." 
• James Forsyth wrote:
  "People need rules, direction and a clear goal, this added to a team leader/ manager that gets buy in from the team, explains everybody’s role and expected outcome and you have the makings of a successful project."

Get in on the discussion!

Linkedin is a great place for project management related discussions. I strongly recommend these groups:

• Project Manager Networking Group 
• PMI Certified PMPs
• Project Management Bloggers
• Project Management Link
• Certified Project, Program & Portfolio Managers

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

What are you? Are you a technical specialist? What's your specialty? What about your team: what's their specialty?

How would you feel if your team members tried to manage the project in your place? How would you like the software engineer trying to replan the project to meet the deadline?

I bet you would not like it. Not one bit.

Yet, how often do we do this to our teams? How often to we try to be specialists in their own discipline?

It's one thing to want to be helpful and to makes suggestions. It's another to assume we know better than they do. After all, we're the project managers because we are good a managing. She's en engineer because she's good at engineering.

Project Managers: we don't need to know everything about everything

It's ok to defer for the technical expert in your team. It's ok if they answer the question and not you. They don't get to do that often.

If they fix an issue, they should be rewarded for it. If you fix a team conflict, that your accomplishment.

It's OK to say "I don't know."

As project managers, our job is not to know everything. Our job is to know where we can find the information.

Our job is to trust and believe that our teams are the best team to deliver on time and on budget. And if they're not, it's our jobs to develop the project team into the best team to deliver on time and on budget. That's our specialty.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

During my vacation we traveled to Europe. We originally planned to stay one week in Paris and a second week in Madrid. After 4 days in Paris, we realized we would get bored if we stayed the whole week. We had two options:

1. Stay and be bored.
2. Pull a map of Europe and choose a place to visit for a couple of days.

We chose to take the train and visit Brussels.

Project plans should allow for flexibility

While it's important to have goals and to know how we will achieve them, it's also crucial to remember that the one thing that is certain about your project plan, is that it will change.

It may be tempting to stay with the plan at all costs. The plan was thought through and approved. It's the path that was chosen to get complete the project.

However, as time goes, what you and your team know will improve, and that will change how you see completing the project. One's aversion to change should not be an obstacle to adjusting the plan.

As @threew said: a plan must allow flexibility.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Background on this post

I wrote this post as a bit of a manifesto. I often have the impression from project managers that, while they expect their teams to trust them, they are not giving the trust back to the team. And it occurred to me that this really was about taking a risk, and managing that risk in the project.

Take the risk of trusting your team

From the part of the person who gives it, trust is hard. It requires a leap of faith. It requires that we believe the person we trust is worth it.

From the part of the person who receives it, trust is energizing. It means that someone was willing to take that leap of faith for us. It means we are worth it. Trust also carries responsibility: if we want to keep that trust, we must prove the giver right. This means delivering on that trust.

Project management requires a high level of trust

• The project manager must trust the team to do quality work on time and on budget.
• The project team must trust the project manager to lead them efficiently and help them meet their deadlines.
• The stakeholders must trust the project manager to understand their needs.
• The project sponsors must trust the project manager to control the project and prevent cost and schedule overruns.

In a nutshell, the project team must trust each other. That includes the project manager, the team, the stakeholder and the sponsors. For most of us, trust is not something we give freely, to everyone. We tend to be careful with our trust. We want people to prove that they are trustworthy before we trust them at all.

From a leadership and teamwork standpoint, this is a problem. How can we know someone can be trusted if we won't trust them? Sure, they may have built a reputation - which helps - but we've never trusted this person before. Or maybe they've never managed such a big project. Or maybe the technology is new to them. There is always a reason not  to trust someone.

Lack of trust is bad

We all know how it feels not to be trusted. It reflects on the opinion people have of us. It taints the perception we have of the person who is not willing to trust us. It's difficult to do a good job if our project manager is constantly double-checking out work. It's even more difficult to build project forecasts if we always question the estimates the team is giving us. Over time, a team that is not trusted will lose its initiative and dynamics. They will turn into drones who simply execute.

It this what we want in our teams? I think not.

Take the risk of trusting your team

Trusting someone is taking a risk. While having that trust broken can have a high impact on the project, it also carries the opportunity of better project performance. Just like project reporting by exception is a technique that saves time, as project managers we should practice mistrust by exception: trust your team by default, and take the trust away from people who have proven they couldn't be trusted.

Isn't it what a risk register is for? :-)

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Background on the posts

I wrote these two posts because I got tired of reading how complicated it was to compute project metrics. Project metrics are NOT complicated, it's simple math! So I thought if I wrote my understanding of those metrics, it might help some people.

It turns out these two posts are the most popular ones on the blog!

I hope you enjoy them :-)

Project metrics: earned value management with a 6-function calculator

Project metrics have a bad reputation. Things like Earned Value and Schedule Performance Index are presented as complex calculations that only experts can master.

Nothing could be further from the truth

Actually, most project metric calculations can be done by anyone with grade-school math skills. The challenge in project metrics calculations is not in the formulas themselves, but in mixing project management concepts with mathematical operators.

Still, these concepts are basic to project management. Every good project manager should understand them.

Start with the basics: Earned Value, Planned Value, Actual Cost

These three are not really formulas. They are the three figures project metrics use to create all the other ones, like the Cost Performance Index and the Estimate to Complete.

• Planned Value is how much you were supposed to do in a given period of time.
  • For example, let's say you're half-way through a  6-month project. Normally, you should be half-way done as well on the project. This means your Planned Value is 50% of the total value (or budget) of your project.
• Earned Value is how much you've really accomplished in the project. 
  • Let's stick with your 6-month project. Let's pretend that you're only 40% done with the project. That portion of your project budget is the Earned Value.
• Actual Cost is how much you've spent on your project.
  • Still with the 6-month project, let's say you've spent 60% of your budget already. That portion of your project budget is your Actual Cost.

Now, let's take those percentages and turn them into numbers. We'll work with a 50 000$ budget.

• 50% of 50 000$ is 25 000$. This is your Planned Value.
• 40% of 50 000$ is 20 000$. This is your Earned Value.
• 60% of 50 000$ is 30 000$. This is your Actual Cost.

But what does it mean?

25K planned, 20K earned, and 30K in expenses. Doesn't it look simpler this way? If we've earned less than planned, one would say the project is late. Moreover, if our expenses are higher than our earnings, one would also say we're over budget.

That's all those pesky metrics are about. Now, we (and our project sponsors) will want to know the actual numbers. I found that understanding those formulas was easier than just learning them by heart.

• The Cost Variance is about the difference between how much has been done and how much it really cost. 
  • Earned Value - Actual Cost = Cost Variance
  • This makes sense. The Earned Value figure corresponds to how much of the project is done. And this proportion should also (more or less) be the same of the project budget.
  • If you're under budget, you'll have a positive number. If you're over budget, you'll see a negative number.
  • For our example: 20K - 30K = -10K

OK, now we know we're over budget by 10 000$. What does it mean? Is this a big number or a small number? 10K on a small project would be a big deal. 10K on a million-dollar project may just be normal variance.

This is why we need a ratio.

• The Cost Performance Index is about how bad (or how good) the project is going, budget-wise.
  • Earned Value / Actual Cost = Cost Performance Index
  • Basically, we use the same two figures from the Cost Variance formula, but we change this symbol ( - ) for this one ( /). We'll compare how much we've accomplished with how much we spent to accomplish it.
  • If we're under budget, the number will be above 1 (100%+). This means we've produced more value than it cost us to produce it. It means we're making a profit in the project. If the number is less than 1, it means it's costing us more to produce the project than we'll earn from it. We're losing money on the project.
  • For our example: 20k / 30K = 0.666

OK. This is bad. We're losing a lot of money on that project. In fact, we're only making two thirds or the money we're putting into the project in the first place.

However, we need to see if the project is just more expensive, or if we're late too - which would mean we're really in trouble with the project. For that we'll need to compare Planned Value and Earned Value.

Essentially, the Schedule Variance formulas are the same as the Cost Variance formulas. You simply replace the Actual Cost with Planned Value:

• Earned Value - Planned Value = Schedule Variance
  • Here, we're comparing how much we were supposed to do (Planned Value), with how much we've really done (Earned Value).
  • For our example: 20K - 25K = -5K
• Earned Value / Planned Value = Schedule Performance Index
  • Here, we're making a ratio to know the proportion that this difference represents.
  • For our example: 20K / 25K = 0.8

If we look at those numbers, we're quite late as well, about 20% slower than planned.

With three simple numbers and two formulas, we were able - with only two of the six functions on that calculator, to tell that our project is late and over budget.

Was that complicated? Hardly.

Variance and Index calculations are simple.  In fact, they use the basic math we learn in grade school. You could put these 4 formulas in a spreadsheet can compute your project metrics with one hand tied behind you back.

Estimates

Estimates seem even trickier than variances and indexes. Because a lot of the original estimating process is fuzzy, it's easy to assume figures like Estimate to Complete and Estimate at Completion would be hard to understand and hard to believe that - Gasp! - they can be computed with a pen and paper.

Just like last time, we'll work with a  6-month fictional project with a 50 000$ budget. In order to compute Estimate to Complete and Estimate at Completion, we need the following figures:

• Budget at Completion is your project's total budget. This is (usually) decided when the project is approved
  • With our project example, the Budget at Completion is 50 000$.
• Earned Value is how much you've really accomplished in the project. 
  • Working with our 6-month project. Let's pretend that you're only 40% done with the project. That portion of your project budget is the Earned Value.
• Actual Cost is how much you've spent on your project.
  • Still with the 6-month project, let's say you've spent 60% of your budget already. That portion of your project budget is your Actual Cost.

Now, let's recap our figures.

• 50 000$ is your Budget at Completion.
• 40% of 50 000$ is 20 000$. This is your Earned Value.
• 60% of 50 000$ is 30 000$. This is your Actual Cost.

Estimate to Complete: what's left to do in your project?

The Estimate to Complete is the remaining work to be done on the project. In order to know how much is left to do, we'll need to know what's been accomplished - this is the Earned Value.

• Budget at Completion - Earned Value = Estimate to Complete
• Contrary to the previous project metrics, this is just a number. It tells us how much is left to do on the project.
• For our example: 50K - 20K = 30K. 

There is another method to compute Estimate to Complete. You can account for higher costs using a typical variance. An example of a typical variance would be if the speed of work was overestimated, and it takes longer to do the work than expected. When you are in a situation like this, you can apply that variation to the rest of the project, and thus have a better Estimate to Complete to work with.

• Estimate to complete / Cost Performance Index = Estimate to Complete with typical variance
• Since we already computed the Cost Performance Index in the last post, we'll use it here.
• For our example:  30K / 0.666 = 45.05K

That makes a BIG difference in how much it's going to cost to finish to project, don't you think?

Estimate at Completion: how much is it going to cost?

Essentially, the Estimate to Complete figure is just a number. We don't know if it's good or bad, until we can figure how much the whole project is going to cost. This is the Estimate at Completion.

This is also a very easy number to compute. You simply add what you've spent already (Actual Cost) and what you think it will cost to finish the project (Estimate to Complete).

• Actual Cost + Estimate to Complete = Estimate at Completion
• For our example (let's use the typical variance): 30K + 45.-5K = 75.05K

Variance at Completion: how off target are you?

The last thing we want to know now, is are we over budget, and if so, by how much? This is another simple computation that gives us the Variance at Completion, the difference between the original budget and the forecast cost.

• Budget at Completion - Estimate at Completion = Variance at completion
• Just like the Schedule Variance and the Cost Variance we worked with last time, if you're under budget, you'll have a positive number. If you're over budget, you'll see a negative number.
• For our example: 50K - 75.05K = -25.05K

The -25.05K tells us we are 25 000$ over budget. For a 50 000$ project, we could say your project is in trouble.

Was that so hard? I don't think so.

For all of you who are worried about passing the PMP exam because of the math skills required, you've just read 80% of the math you are expected to use in the PMP exam. As long as you understand these formulas, you have nothing to worry about.

Here is a spreadsheet with all those nifty formulas.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

It's been requested for a long time. After all, cost or part of the project management triangle, along with schedule and scope. While AceProject allows for management of the schedule and the scope of the project, no dollar signs could be found in the application.

That's about to change

With version 4.8, scheduled for the end of the year, AceProject will include the following cost tracking features:

• Entering an hourly cost rate for each user
• Logging expenses for a task and/or a project
• Entering estimates for expenses as well as hours
• Entering a budget for the project
• Reporting on expenses and labor costs
• Comparison to budget and estimates
• Disabling or enabling both cost tracking and time tracking features at the account level

As development progresses, we'll share some screen captures with you here.

Our goal is to introduce a way to manage project costs that is simple and user-friendly. Our challenge is to keep AceProject balanced between its ease of use and a comprehensive feature set, and we expect that the cost tracking features will test us on that level.

What do you think? How should we implement cost management in AceProject?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

It's the high vacation season here in Canada. Since July is the warmest month of the year, it makes sense that most people take time off during that period.

Vacations are good for the body, the mind and the soul. It's not just about resting, vacations give us an opportunity to change the focus of our lives, from our work to something else. A different place to be, different activities, more time with our families.

For me, vacations are also an opportunity to rethink an issue or gain fresh perspective on my projects. Begin out of the office changes how we see things. Sometimes this is what we need to come up with an innovative solution.

Every year, when I leave on vacation, I choose one thing to reflect upon during my vacation. When I come back, I don't always have a solution (epiphanies don't happen upon request, you know), but I always have better understanding.

What will you be thinking about during your vacation?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

We receive suggestions for new features every week. When I do live demos with future clients, they regularly request new features as well.

We really like receiving these suggestions. They give us a pulse of the market, of what people are looking for.

A year ago people were asking for Salesforce integration a lot. Six months ago it was baselines. These days, people are asking to automated resource leveling.

Now I'm not saying those are not great features to have in AceProject. Quite the contrary. However, these requests come and go. They're trends.

Over the last 2 years, one feature that has been requested consistently is cost-tracking. It's a big feature.

And we've decided to do it!

Cost tracking will be included in AceProject 4.8

We chose to develop the cost tracking feature because it's been requested consistently for a long time. This tells us it's a true need for AceProject, not just a trend. Seeing how implementing cost tracking will take a lot of time and effort, we wouldn't have done if we had identified it as a trend.

Next time: I'll tell you about cost tracking in AceProject! We're still in the design phase, so your comments are greatly appreciated.

Whenever someone wants a walk through of AceProject, I am the one who sets up the web meetings and shows them how they can manage their projects and their clients efficiently with our system. I have been giving demos every week for the last 18 months, and I have yet to see two clients with the same needs. Of course, the higher-level needs are more common (collaboration, project management, document management, etc.) But how each client wants to implement this processes in their organization is different every time.

Now AceProject is a tool. It's something that will help you get things done. It's not going to do the work for you. It's not going to force you to go things a certain way.

All tools should be flexible. Not everyone who wants to manage projects needs milestones. Not everyone wants dependencies.

Each organization is unique, and each project manager is unique. Project management tools should accommodate this uniqueness in their product. After all, who are we to tell you how to run your business?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

I recently had the chance to sit it on a very informative presentation about the changes to the PMI's Project Management Body of Knowledge 4th edition, aka the PMBOK. It's important to stay up-to-date on profesionnal best practices, and there's been a lot of discussion on the new PMBOK.

I'll spare you the details of the new processes and the deleted processes in the system. I'll spare you the details of the new flowcharts.

Here's what stuck my about the changes in the new PMBOK: it put more emphasis on the human side of project management. Managing stakeholders is more important.

There's even a whole section about interpersonal skills, Appendix G, which talks about leadership, team building, motivation, communication, and so on.

"Respect and trust, rather than fear and submission, are the key elements of effective leadership." - PMBOK 4 th edition, page 448.

I believe it's the first time the PMI takes a real stance about management styles and personal interaction.

It was not a minute too soon.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Last week I had the pleasure of meeting Bruno Larouche from Génération Agile. He helps businesses implement agile methodologies. We had a conversation on Twitter earlier about AceProject's compatibility with agile project management.

Bruno gave us a very enlightening presentation. While I had read about agile before, I don't think I had ever had the chance to talk with someone who lives and breathes agile. One thing that hit me as Bruno was explaining what agile project management was about, is the importance of the human in Agile development methodologies.

What I learned about Agile project management and humans

1. Agile is about adapting to change. The Agile project team must react to changing conditions in our environment.
2. Agile project management stresses fulfilling a need. It's important to manage stakeholders' expectations well.
3. It's crucial to involve the client (or at least a representative of the end users) early in the process. There's no point in asking for feedback when it's too late to change anything.
4. Communication and motivation are essential to deliver early and often.
5. The project manager is never alone: the team provides estimates and participates in sprint planning.

Is Agile project management simply really good teamwork?

When I was listening to Bruno, I felt that Agile methodologies stress the importance of teamwork: assigning the right people to do the job, trusting people, empowering the team in project planning. Those are all important notions that all good project managers should apply, even in more traditional project approaches.

It seems to me that Agile has reintroduced important concepts of working together.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Yes, it's finally ready! AceProject server will be upgraded tomorrow night to version 4.7.

Here are the release notes.

Congratulations to the team for such good work, and I hope you like the new version!

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

What happens once you've passed the PMP exam? Keeping up with 60 Pofesionnal Development Units (PDUs) every 3 years can seem like a daunting task.

I've written a post about just that on Josh Nankievel's blog, pmtsudent.

Enjoy!

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Leadership is much more than a skill. While we may learn to tailor how we communicate with others to influence them to follow us, can we really learn a personality trait?

What is leadership?

Leadership can be seen in two ways:

• As the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task”.
• As "creating a way for people to contribute to making something extraordinary happen."

While learning to influence others is a skill that can be learned, it feels a lot like manipulation to me. Leaders that use manipulation consciously to get people to do what they want seem dishonest to me.

I think true leaders hold a deep belief in their cause or goal, a belief that is infectious. They don't need to convince or manipulate others to follow them in their projects. People want to follow them. That's natural leadership.

While leadeship skills may be learned, natural leadership cannot

Natural leadership is a personality trait. It requires personal conviction, self-confidence and extroversion.  Think about the natural leaders you've met: the great bosses you've had, the teachers you will never forget, the friends who made the gang special. What they had that made them natural leaders was not learned. They were born with it.

What do you think? Can leadership be learned?

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

There are two schools of thought with project management tools: project management OR collaboration.

Why should project teams have two tools, one for project management and one for collaboration? Shouldn't both these uses be united in one tool?

Project management is not about secrecy, quite the contrary. It's about sharing information with everyone who needs it. Project management is about getting your team to work together to achieve results.

When using a collaborative project management system, you not only share information on the project with the team, your stakeholders and even your clients, you also get to share the burden to updating project information with your team. Instead of the project manager being the only one updating task statuses and entering time sheet data, it's everyone in the team who does. The project manager simply double-checks and approves the updates.

Not only does it save tremendous amounts of time, it also empowers the team. It gives the team members responsibility towards the project, beyond their assigned work.

I went fishing last weekend. It was a beautiful (yet a little cold) weekend in the woods. We were on a good lake for fishing: our quota was 15 catches per person. That's a lot of fish!

We were thinking: if the outfitter allows 15 catches per person, there's got to be a lot of fish in this lake. And there was. As we arrived the Friday night, we could see the bass jump at flies on the surface of the lake. We were stoked for a good day of bass fishing on Saturday!

Well, it was not a good day of fishing. We caught a total of 10 fish between the three of us. This was underwhelming.

Here's why we didn't get the fish we were hoping for

1. The fish was jumping at the flies, but we were bait-fishing. Wrong technique. Wrong approach. If the fish is going for flying insects, it won't respond to bait just floating there, will it?
2. The mayflies were swarming the lake. Mayflies look like mosquitoes, but they only live a few days, and their main purpose is to be food for other species. The fish were gorging on the mayflies, so they were even less interested in our bait.

The same two things happen in project management

If we look at the fishing story, two things happened: one was under our control, and the other wasn't.

Know your environment

We could have planned for fly-fishing and brought both type of fishing rods. Actually, it would have paid to call the outfitter a couple of days before coming to the lake to ask them which type of fishing works best.

In a project setting, this translates to knowing your team, your stakeholders and avoiding the cookie-cutter approach. All humans are different and they need to be managed accordingly. Some people respond well to a direct approach, other people prefer a softer, relation-based approach. As project managers, we need to adapt to the people we work with and the environment work in.

There are some things you can't control

Just like the mayflies, sometimes things happen in a project that are truly out of your control. Someone in your team may get sick or leave the company. The City might pass a new bylaw that makes your project more complicated. It's normal. It's to be expected. And we just have to deal with it when it comes.

Of course, if we've been keeping up with our environment, we may be able to identify some of the uncontrollable risks ahead of time and plan a contingency margin. However, no matter how much we plan, the unexpected just can't be planned for.

So, what's to do?

Take it all in stride is what we should do. We can't control everything. Our job as project managers if to do the best we can with the situation.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Last week at the Webcom conference, the big buzzword was open: open networking, open mesh, open social, open products, etc.

The era of the Web 2.0 is over. It's now the Web ME.0.  ME.0 is about the individual. Not the products. Not the technologies. Not the businesses.

The people.

And those people are not interested in remembering 15 different passwords, or recreating 15 diffierent profiles on 15 different sites and products. Already, we're seeing most sites using the email address as the username to log in. We're seeing initiatives like OpenSocial getting attention from the likes of Google and Yahoo. We're seeing more and more products opening their databases via APIs. We're seeing more products designed to centralize social network updating.

Businesses are making their products easier to use, instead of locking their customers in.

Everyone wants an open product, an open platform and an open relationship with their suppliers and clients.

Open is THE online business and technology trend this year, just like green is THE brick-and-mortar business trend this year.

Project management is a big world. With the PMI's PMBOK running at 400 pages or so, it can be challenging to keep up with methodologies. Even more challenging is keeping up the practice of closing projects well. It's easy to sign-off on the work and to do the administrative closure stuff, but building good, usable project achives is harder. It takes time, and the value of this time is not seen in the short term.

I recently attended a conference from Laurent Bellavance, the director of Rimouski's economic promotion society. His role is to facilitate the projects: he puts together the local governments, specialists and investors to create innovation and prosperity in his city.  Bellavance has been in his post for about a year. One of his challenges is to get information on past projects. While the other directors who preceded him at the head of his organization can still be reached if needed, they are focussed on other goals and do not always remember the specifics of projects that have been closed for years.

There are paper archives, but those aren't convenient for searching. It takes time, there's not index...and what were people doing before Google?

Project historical information must not be allowed to live only in the heads of the project team

Desktop-based project management systems are not convenient for storing information. Even if you can keep the project schedule, there is little room for documentation, notes, lessons learned. And most of it lives on someone's hard drive (and we all know how fickle these things can be). Organizations like Bellavance's should use a collaboration tool, to keep all the information centralized. With online project management and collaboration, the data lives in a place that is accessible from anywhere, easily. It's searchable.

With an online project management and collaboration system, you get a chance to store project archives outside the project team's memory. A few years later, you can go back to a closed project and find that contact information that got lost in the email system changeover, or you can search your issues knowledge base across projects to fix a problem with an SQL query.

When that kind of information lives in someone's head, it can be forgotten, or the person can move on to other challenges and no longer be available. And that's when a lot of organizations understand the value of project archives.

Well, what do you know? AceProject does just that!

One reason that people like AceProject is because no project is ever deleted. All the information that was entered in AceProject during the life of the project can be searched: documents, discussion forums, comment threads in tasks, reports, etc. There is no need to transfer all that information in a knowledge base, when you're using AceProject, you're building the knowledge base as you go!

The world of project management is a crowded place. There are multiple profesional accreditation options, multiple project management methodologies and countless books, blogs and tools to manage projects.

This is a good thing. I have never talked to two organizations who managed projects the same way. It makes sense that there would a wide range of options.

In most markets, when you sell something, the other products that are sold to do the same thing as your product are called competition. The customer base is finite and the game is to win over the heart of a majority of those customers. When we talk about AceProject and the world of project management software, this feels wrong to me.

There are many, many, many project management tools out there. Open source tools, free tools, affordable tools, expensive tools, web-based and desktop-based. The Google search for project management tool comes up with 188 million results. With that many players in the race to win over users and fans, how can we even see it as a competition? 

I prefer to see other companies making project management tools as colleagues.

Colleagues are more civilized. We work in the same field, but our products are aimed at different needs, different types of companies and project management methodologies. Our vision of doing business at Websystems is not to talk against other project management tool providers, but to show potential clients how AceProject fits with their project management needs. We don't want to cheat people into creating an account with us. If AceProject is not a good fit for the project team's needs, it's fine. We'd rather see that team succeed with a tool better adapted to their needs, than have them struggle when AceProject is not what they're looking for.

Go Ahead, Manage is over one year old. I know, it's young compared to most of the blogs out there. I've been writing the majority of Go Ahead, Manage's content. After a year, I find that the greatest challenge is to have something to say.

This blog is not about my personal life, but about the life of the whole team here, the life of our product, AceProject, and the life of our field, project management.

When we began this blog, I had a lot of things to say, I even had a backlog! As time passed, I got through that backlog and now I find my inspiration a few minutes before I start typing the new post away.

The biggest lesson I've learned about blogging is that it requires discipline to produce new, fresh content three times a week. In the last few months, with Twitter taking the world of project management by storm, there is even more content out there about project management, project managers, and managing a business. It becomes a challenge to create content that is remarkable and unique, amid all the other great blogs out there!

However, keeping up with all those blogs and Twitter hashtags is keeping me and the whole team here at Websystems on our toes. It is also a great source of inspiration, both for the blog and for the future of AceProject.

Development is going well for AceProject 4.7 (see what's we've written already here, here and here). We are finishing phase 2 of development.

Eye candy

Here is some eye candy for mac users: a brand new skin!

Project templates

People love AceProject's templates because it makes creating new project very easy. You simply copy an existing project, and you can even adjust task dates based on the new project start date.

With AceProject 4.7, we've added the possibility to reset task statuses, so you don't need to create pure templates if you don't want to:

Better time sheets

Time sheets are one of the most-used features in AceProject. With version 4.7, AceProject will automatically create time sheets at the beginning of each week.

To make it easier to fill out the time sheets, it will be possible to enter time worked in the hours:minutes format. AceProject will convert the hh:mm entry into a decimal number automatically. That will make time sheet more usable.

Project metrics have a bad reputation. Things like Earned Value and Schedule Performance Index are presented as complex calculations that only experts can master.

Nothing could be further from the truth

Actually, most project metric calculations can be done by anyone with grade-school math skills. The challenge in project metrics calculations is not in the formulas themselves, but in mixing project management concepts with mathematical operators.

Still, these concepts are basic to project management. Every good project manager should understand them.

Start with the basics: Earned Value, Planned Value, Actual Cost

These three are not really formulas. They are the three figures project metrics use to create all the other ones, like the Cost Performance Index and the Estimate to Complete.

• Planned Value is how much you were supposed to do in a given period of time.
  • For example, let's say you're half-way through a  6-month project. Normally, you should be half-way done as well on the project. This means your Planned Value is 50% of the total value (or budget) of your project.
• Earned Value is how much you've really accomplished in the project. 
  • Let's stick with your 6-month project. Let's pretend that you're only 40% done with the project. That portion of your project budget is the Earned Value.
• Actual Cost is how much you've spent on your project.
  • Still with the 6-month project, let's say you've spent 60% of your budget already. That portion of your project budget is your Actual Cost.

Now, let's take those percentages and turn them into numbers. We'll work with a 50 000$ budget.

• 50% of 50 000$ is 25 000$. This is your Planned Value.
• 40% of 50 000$ is 20 000$. This is your Earned Value.
• 60% of 50 000$ is 30 000$. This is your Actual Cost.

But what does it mean?

25K planned, 20K earned, and 30K in expenses. Doesn't it look simpler this way? If we've earned less than planned, one would say the project is late. Moreover, if our expenses are higher than our earnings, one would also say we're over budget.

That's all those pesky metrics are about. Now, we (and our project sponsors) will want to know the actual numbers. I found that understanding those formulas was easier than just learning them by heart.

• The Cost Variance is about the difference between how much has been done and how much it really cost. 
  • Earned Value - Actual Cost = Cost Variance
  • This makes sense. The Earned Value figure corresponds to how much of the project is done. And this proportion should also (more or less) be the same of the project budget.
  • If you're under budget, you'll have a positive number. If you're over budget, you'll see a negative number.
  • For our example: 20K - 30K = -10K

OK, now we know we're over budget by 10 000$. What does it mean? Is this a big number or a small number? 10K on a small project would be a big deal. 10K on a million-dollar project may just be normal variance.

This is why we need a ratio.

• The Cost Performance Index is about how bad (or how good) the project is going, budget-wise.
  • Earned Value / Actual Cost = Cost Performance Index
  • Basically, we use the same two figures from the Cost Variance formula, but we change this symbol ( - ) for this one ( /). We'll compare how much we've accomplished with how much we spent to accomplish it.
  • If we're under budget, the number will be above 1 (100%+). This means we've produced more value than it cost us to produce it. It means we're making a profit in the project. If the number is less than 1, it means it's costing us more to produce the project than we'll earn from it. We're loosing money on the project.
  • For our example: 20k / 30K = 0.666

OK. This is bad. We're loosing a lot of money on that project. In fact, we're only making two thirds or the money we're putting into the project in the first place.

However, we need to see if the project is just more expensive, or if we're late too - which would mean we're really in trouble with the project. For that we'll need to compare Planned Value and Earned Value.

Essentially, the Schedule Variance formulas are the same as the Cost Variance formulas. You simply replace the Actual Cost with Planned Value:

• Earned Value - Planned Value = Schedule Variance
  • Here, we're comparing how much we were supposed to do (Planned Value), with how much we've really done (Earned Value).
  • For our example: 20K - 25K = -5K
• Earned Value / Planned Value = Schedule Performance Index
  • Here, we're making a ratio to know the proportion that this difference represents.
  • For our example: 20K / 25K = 0.8

If we look at those numbers, we're quite late as well, about 20% slower than planned.

With three simple numbers and two formulas, we were able - with only two of the six functions on that calculator, to tell that our project is late and over budget.

Was that complicated? Hardly.

Variance and Index calculations are simple.  In fact, they use the basic math we learn in grade school. You could put these 4 formulas in a spreadsheet can compute your project metrics with one hand tied behind you back.

Next time, we'll tackle project estimates.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.

Virtual teams are a fact of today's projects. With outsourcing and increased mobility for the workforce, there is a higher proportion of people who either work in satellite locations, or simply work from home.

The project team becomes virtual. How can we keep up with everyone when we can't see them?

A huge part of project management is getting a feel of how the team is doing

How can we do that without seeing the people we work with? After all, the biggest part of a person's message is not conveyed with words. It's transmitted via pitch and intonation of voice, the way she sits or stands, her facial expressions and hand gestures. These are all things someone can't show in an email, a tweet or a chat window. And while video conferencing and conference calls can help getting a bit more from that team member, it's still not the same as being right in front her.

Another issue is created by writing instead of talking. In writing, people have different personalities. When we write something, it's not spontaneous. We get to re-read it, improve the message and control the information we send more closely. This means that someone can be very unhappy about something in the project, and never express it in her communications. Weeks or months later, the problem has grown exponentially and it may not be fixable anymore.

A third issue with virtual teams is the ability to hide things better. Since the project team is not in a war room and the team is not physically together, a team member who would have difficulties would be able to hide it from the team and her project manager. This can cause significant delays in projects, and even compromise the whole project.

As a project manager, how can we adapt to the virtual team?

Step 1: Remember the eyes. One very important thing is to keep something visual going on during a conference call (this article has good examples of desktop sharing applications). I'm sure everyone has been on a conference call while doing email at the same time :-) When there is a visual element to the virtual meeting, it's easier for everyone to stay focused on the subject.

Step 2: Don't skip the one-on-ones. Even if it's only by phone of chat, it's important to dedicate time to each of your team members. The easiest way for me is to plan a weekly 30-minute meeting with each person. When someone works from home, it's very easy for her to feel left out if no one takes time to talk to her personally. The one-on-one is a great time to get a feel of how things are going with this person, without everyone else listening in on the conversation. Actually, with virtual teams, this a must. If you don't have those one-on-ones, you have very little chance of learning that a team member's kid has been sick lately, or that she's having technical issues with one of her tasks.

Step 3: Keep it social. If at all possible, have a face-to-face kick-off meeting, and have a party when a big milestone in you project has been delivered. The fact that people don't work in the same place doesn't mean they don't work together. Getting the team to know each other (and their project manager) will help everyone adapt their working habits to suit the team.

With the Vancouver Olympics project getting a lot of attention worldwide, the Candian chapters of the PMI have organized a Project Management Week. This is a great time for all Canadian project managers to inform and train their teams about project management today.

The Globe and Mail and the French paper Les Affaires will be running a special insert next week, and your local Canadian PMI chapter has events lined up for you to attend!

To get involved virtually: join the LinkedIn group for the Canadian Project Management Week.

Websystems will be closed today for Easter Monday. I hope you enjoy this time with your loved ones, and I wish you all a sunny Easter weekend!

A project should not be composed a leader on top and everybody else below. Actually, that's a very good way to fail. Your team is there for the project, and so are you. Why not work together?

You need to work together.

Be with your team. Spend time with them. Take the time to explain what's going on in the project.  Listen.

When problems arise (they always arise), your team's unique perspective may be the key to solving it. Budget problems? Maybe one of your developers knows a less-expensive tool that does the job just as well. Schedule problem? Your QA specialist may have a few tricks up her sleeve to speed up the testing phase.

Project managers are not superheroes. We can't expect to fix everything on our own. That's why there are project teams.

The project can't succeed without the team, but it can succeed despite the project manager.

Seth Godin has a very insightful post about ignoring your critics.

I agree with him.

From a sales standpoint, critics are everywhere. People who are shopping for project management software often have a very definite set of features they would like to see in their tool. And when they are faced with the reality of an actual project management system, which cannot possibly include all the features everyone ever wanted, they may say something like "I would definitely buy AceProject is it did X."

The problem is, if we added every feature asked during the sales process, AceProject would be a mess. It would have so many features, it would be unusable. And no one would want to buy it.

So, we need to balance what we choose to add to AceProject. If it keeps coming back (like task dependencies being too hard to use), we should do it. If it's been asked only once, we'll wait.

I just watched this nice video on how to trick Excel into making a Gantt chart.

It's not that the process seems difficult, it's just very time consuming:

1. Create your task list, with start dates, durations and end dates.
2. Create a stacked bar chart form this data.
3. Modify your bar chart to make the start dates invisible.
4. Modify your bar chart to make the tasks appear in the correct order (in ascending order of start date).
5. Modify your bar chart legends so the right date range is used.
6. Modify your bar chart axis divisions so that you can easily see if some tasks overlap.

My brain hurts.

I imagine there is a way to create templates to speed up the creation of the Gantt chart, but it still seems like twisting Excel into doing something it wasn't designed to do in the first place. I understand that since pretty much everyone has Excel already installed on their computers, it seems like this process gives Gantt charts to project managers, for free.

Here's the problem: your time is not free.

Think about it: how much time will you spend making Gantt charts in Excel? At the end of the year, all those 15 minutes add up to a lot of hours, and that means a lot of money for you, your employer, and your client.

15 minutes per day, 3 times a week, for 48 weeks per year represents 36 hours.  This means using the free Excel Gantt chart tool costs thousands of dollars in salary.

Wouldn't you have better things to do with those 36 hours?

That's where project management systems come in.

Project management systems like AceProject are built to create Gantt charts. All you need to do is build your project's activity list, and the system will create the Gantt chart for you. With the right dates, and the correct time scales, and even shows progress on your activities!

AceProject is available for free, and costs at most 1000$ per year. No need to twist a product into something it's not. And this means more time for you to do what you should be doing: helping your project teams along.

Here's a very interesting (and inspirational post) from Rands in Repose. The post uses the building of the Brooklyn bridge as a metaphor for breakthroughs. In the beginning of the article, he explains the intentions of the ferry operators in New York City before the bridges were built: they didn't want to build something great. They just wanted to make a profit.

Go read the article. It's worth the fifteen minutes you'll invest.

Do you want to build something great or make a profit?

People who just want to make a profit are not pushed to greatness. People who want to build something great don't care about the money. It's the same with business and projects.

However, something strange happens. People only interested in profit inevitably end up loosing to the people who want to built great things. And people who want to build something great usually end up with a better product.

Greatness lives in small things, too

When we build a new version of AceProject, when we decide the new features we'll add, or which ones we'll fix, the team has to be focused on making something great. On making AceProject the best it can be...for now. It creates very animated, very passionate discussions and disagreements in the team. It's not easy. But when we're ready to release the new AceProject version, everyone is immensely proud of what we've done.

I'm sitting in the train, coming back home to Quebec from Montreal. Via Rail, the train company, offers WiFi connectivity for 8.95$ per day. That seems a little expensive to me, so I decided that me and my laptop would go alone. Offline.

That’s when I realized how much time I spent online, for my personal and my work life. AceProject is an online project management system. Everything we do at Websystems is somehow connected to the Internet: the CRM, the system, our VOIP phones, the email server. If we were to lose our Internet connection at the office, most of us would be sitting idly until it comes back.

So here I am, sitting in a train, without Internet access on my laptop. And my laptop feels useless. If I can’t read my RSS feeds, check website performance statistics, stay up-to-date on customer requests, manage my projects or even keep up with the daily email, what’s left to do for a project manager/sales & marketing person?

I'm still looking.

I keep finding websites that NEED Internet Explorer to work correctly. On the last website I visited, a government directory, the search function would only work with Internet Explorer.  This is inexcusable. While Michel, our graphic designer, keeps telling me how hard it is to make AceProject look the same across five browsers (Internet Explorer, FireFox, Safari, Opera, Chrome), it can be done.

It doesn't have to be perfect. But it has to work.

Forcing your visitors to stick to a specific browser or a specific screen resolution will only increase your bounce rate.  

On AceProject's website, only 49% of all visitors use Internet Explorer, while 40% use FireFox, 4.75% use Chrome and another 4% uses Safari. If we only support Internet Explorer,  we would turn our backs on more than half our visitors.

Neal Shen wrote a very interesting post on the PMI blog, titled: The First 100 Days...

Neal argues that when being assigned on an existing project, it can be a challenge to get up to speed and build good relationships with your project team. I completely agree with the 3 Ls of communications management: Listen, Learn, Lead.

There's a reason why Lead is last

You can't lead effectively if you're ignorant. Ignorant of your project, ignorant of your team. Once you've built a good understanding of the project and the people, then you can choose a leadership style that fits the situation.

In AceProject 4.7, we introduce non-mandatory dependencies. Those are dependencies that don't require the predecessor task to be completed before the successor can start. For example, you don't need to be done buying presents before you can start wrapping the ones you've got already.

Graphically speaking, we needed an icon that people would click to switch the dependency from mandatory to non-mandatory.

And that's where things get interesting

How do you symbolize mandatory? Our graphic designer, Michel,  and I looked up on Google images and in icon banks, we could not find a consensus, a standard symbol that would mean mandatory. We didn't want to invent something. If you need to explain your icon, you've defeated the purpose of using an icon.

This is when Michel had a great idea: why not use the line that illustrated the dependency between tasks so show whether it's mandatory? A dotted line () would mean non-mandatory, and a solid line () would mean mandatory.

The solution was simple, but the road to reach it was not. 

This is the joy of graphic design.

We often think about optimizing our day, our work life, our home life. And by optimizing we thing or improving how we do things.

Here's something else to think about: how many things to you do every day? How many of those things could you automate?

A good place to start is email. Most of us start the day by sorting and processing the email that came in since we left work the day before. Could you setup rules to automatically sort emails, automatically forward emails to the right people? The amount of time you will invest in setting up the automation will pay for itself in no time.

Here at Websystems, we receive payment confirmations via email and we need to sort those emails in the morning. It doesn't seem like a time-consuming activity (it takes Sylvain about 20 minutes every morning to sort payments). However, if we count 20 minutes per work day, the total is 80+ hours! That means that Sylvain spends over two weeks a year just sorting emails.

Implementing an automated system to sort the payment emails would take a few days of development work. Those 2 or 3 days of extra work form the developer would add 2 weeks of productive time to Sylvain's year. 

It's not always about doing things better. Optimization is also about automating the right things. 

We've added two case studies to AceProject's web site. Those are stories from real clients, telling us how AceProject helps them work better with their clients, with their employees, and with their students.

We are currently working on AceProject 4.7. Since we've implemented agile-style development methods, we have been packing more into our version releases. The issue we are having is estimating how long it's going to take to build something, and ultimately how much new stuff we can put in the next version.

Because our developers hate to be late, they tend to over-estimate the time it will take to code something. So we end up with a nice problem: things get finished faster than expected. It's better than being late. But then, how much more could we put in the release if we had estimated better?

It seems to me it's only a few years ago that Internet Explorer took 80%+ of the browser share from my website visitors. 

How things have changed. Internet Explorer is now used by only 49% of AceProject's visitors, while FireFox is preferred by 40% of them. FireFox and Internet Explorer are now nose-to-nose.

Recession is on everyone’s mind these days. Whether your organization is currently affected by the economic conditions or not, most of us are looking at your spending, to see if where we can save.

Another place to look is your partners: your business partners, your suppliers, your clients. If your main supplier goes bankrupt, it could affect your business as significantly as if your biggest client cancels all orders.

In a recession, the businesses that survive are those with the least debt and those with enough cash flow. As sales may dwindle from lower demand, businesses that are debt-free will be able to weather the storm, while those with a lot of debt would fold under the pressure of the payments.

Furthermore, recessions are good times to invest, to be ready with new offerings when demand picks up on the other side of crisis. Because demand always picks up, sooner or later. However, if all R&D activities are suspended while money is tight, the business falls behind its competition, and it’s very difficult to pick up that lag when times get better.

Websystems is debt-free. Our business strategy has always been to spend money we have now, and not the money we hope to get. Websystems was born during the 2001 dot.com crash. We started at a time where businesses were closing all around us. Being debt-free makes it possible for us to invest in our product.

In a way, this is our second recession, and we will go through this one the same as 7 years ago: by working hard at building the best AceProject we can. We are planning a complete rebuild of AceProject. We are taking advantage of the slower times to focus on our application and rethinking the whole thing.

These are very creative times here at Websystems.

The results from the survey are in. It was our first-ever survey here at Websystems. Here's a summary: 

Which feature do you use most?

1. Task management
2. Time Sheets
3. Project management
4. Gant charts
5. Task comments

Which feature do you like the most?

1. Email notifications
2. Task Management
3. Time sheets
4. Tracking task and project status
5. Reports

Which feature do you like the least?

1. Time sheets
2. Email notifications
3. Reports
4. Task creation workflow (tabs)
5. Search

What's interesting is that then time sheet module, email notifications and task management are present in all three answers. It seems time sheets and email notifications are either loved or hated. Among the comments we received, being able to edit the time sheet for the whole week (like a grid) and being able to customize how email notifications work were the most frequent.

However, people told us they loved to receive those email notifications. We were also told that time sheets are very easy to use.

Overall, what you told us is that you think our reports and our task creation workflow should be a lot better.

We hear you. Your comments were very insightful and we will make sure to keep the good stuff and fix the bad stuff.

I’m a fan of Starbucks coffee. I love the taste and I love the atmosphere for their coffee shops.

In Quebec City, there are three Starbucks stores, and I have my favorite. Because the clientele is different at each place, and because I’ve developed a friendship with the baristas there.

Went I visited New York City for the holidays, I was really looking forward to being in a city that had a Starbucks on every corner (at home, I have to drive a few kilometers to reach one).

Over the 5 days that I spent there, I must have visited at least 6 or 7 different Starbucks stores. And almost every time, I was disappointed. It just didn’t feel the same. Even though it’s the same coffee, the same furniture, the same ads and posters on the walls – they even have the same blackboard drawings!

But it didn’t feel the same as my store here at home.

The difference is the relationship
Even though all the variables are controlled in chains like Starbucks, so that a customer’s experience can be the same anywhere they go, there is one thing that cannot be identical from place to place: humans.

We form relationships all the time: with the people we do business with in our jobs, with the cashier at the grocery store, with our coffee shop baristas. Those relationships have a great influence on our customer experience with the company they represent. In the end, they will bias the opinion we have of the company and its products.

How are your relationships?
How to you see your customers? Are they once-in-a-lifetime opportunities or people you hope to see on a regular basis?

Because AceProject is a hosted solution, we tend to develop more of a relationship with our customers. What’s even nicer, is when an AceProject user changes jobs, and brings AceProject over to the new company – it’s the most rewarding endorsement we could hope for.

AceProject will be closed for the holidays, between December 24th and January 4th, 2009. We will still be monitoring the servers and the support email inbox, so if you have an emergency, write us at support@aceproject.com.

Everyone here will take this time to relax, recharge our batteries and have some quality time with our families.

We wish you the same :-)

Moving a brochure from an idea to a layout to an approved proof to a box of printed copies is no easy task.

With AceProject, printers can move files from one process to the next, and make sure that all the approvals are given before the file goes to the next process.

At most printers, there are workstations near the presses. Those are not necessarily assigned to specific users. If you want to create a workflow that doesn't depend on who's running this part of the workflow, simply create users based on the process.

However you'll need to make sure there is an email associated with this user, so they can receive email notifications.

(click to enlarge)

Involve your clients

If you often work with the same clients, you can even give them access to AceProject, with limited rights, so that they can upload files, request quotes, or approve work before sending it to press.

(click to enlarge)

(click to enlarge)

Set Finish-to-Start dependencies

In AceProject, if you link two tasks together with the Finish-to-Start dependency, it's not possible for the second task to start unless the first one is completed. This prevents jobs from going to press before the client has approved the proof, for example.

(click to enlarge)

  (click to enlarge)

Use the History Trail to keep track of approvals

When working with client-focused projects, it's important to be sure that a task was approved by the right person. It's also a good idea to keep a log of everything that was done, to avoid misunderstandings. With the History Trail, all changes to a task a kept, along with the user and the time stamp.

(click to enlarge)

Take advantage of project templates

Templates are very good at two things:

1. Save time when creating a new print job
2. Make sure all projects are managed the same way
   

Simply setup a basic project, with the steps that must be done for each project. You can also setup task dependencies. Then, have all the workstations assigned to the project template and create a workflow to reuse whenever you have a new print job.

When you create a new project from this template, AceProject creates the whole project, adjusts dates based on the new project start date, and emails everyone about the new tasks.

  (click to enlarge)

Keep an eye on your presses workload

It's important to deliver your print jobs on time. It's even more important to make sure your presses are not over-allocated. If you setup your presses as users that can't login in AceProject and assign them work hours, you'll be able to know, with the Workload report, the press time required for one day is over its capacity.

(click to enlarge)

   (click to enlarge)

Keep on top of due dates with Task Reminders

Every day, AceProject sends an email to the list of things to do. Set up the Task Reminder to send an email 2 days in advance, and you will receive, every morning, what needs to be done on that day and the following day. (click to enlarge)

Know which jobs you've done for a client

Create your clients in AceProject, and associate each client to a print job. Then, at the end of the year, you'll be able to know how many projects were completed for this client. It's also a good search tool, if a client wants a reprint! (click to enlarge)

Last month, Melinda Cline gave a presentation about using AceProject to teach her students about management information systems and project management systems.

Here are her conclusions:

"Using AceProject, students have an effective tool to increase their understanding of planning, organizing, controlling, and monitoring projects in a global environment.  It is a cost effective way for instructors of project management and other IT management topics to introduce students to project management software without having to buy Microsoft Project licenses, which may be very expensive.  It also has the advantage of being a web based tool with 24/7 access by students and instructors."

You can download her PowerPoint presentation here.

AceProject is used by a wide variety of businesses, in many fields, from construction to health to marketing to product development, and then some.

In this series of articles, I will show you how AceProject can be adapted to a specific field of business.

Part I: Consultants

When you're a consultant, time is money. Literally. What consultants sell is their time. So it's very important for them to be able to track and manage their time accurately.

Moreover, when all your projects are client-related, it's crucial to track billable vs non-billable time, and to respect the time allocated to the project. 

Setting how time is managed

In AceProject, you can configure how you will track and manage time.

First of all, you get to decide how your week works: It can start on Saturday, on Sunday or on Monday. Week management is set in Administration > Configuration > Account Info:

(click to enlarge)

Then, you get to decide how time will be categorized in your account. You're not stuck with default values that have nothing to do with being a consultant. Time Types are configured in Administration > Configuration > Time Types:

 (click to enlarge)

Once Time Types are set, when you fill out your time sheets, you can record Billable Time in your time sheets:

 (click to enlarge)

Recording time on tasks and projects

AceProject lets your team record time three ways. 

With the traditional time sheet, in My Office > My Time Sheets > My Weekly Time Sheets:

(click to enlarge)

With the IN/OUT module, a timer that fills out the time sheet automatically when you close it. You can open an IN/OUT via the task itself or My Office > My Time Sheets > My IN/OUT:

(click to enlarge)

Directly on the task with the Add Time button:

(click to enlarge)

Tracking time budgets

When you create a task, you set a time budget in the Estimated Time field. As people work on your project, they will log time. The task will show, in real time, how much of the budget is spent, in the Actual Time field, and the percentage ratio, in the Actual % Done field:

(click to enlarge)

At the project level, you can even see this data in a table, directly in the Incomplete Tasks page, for all tasks. It makes it even easier to know which tasks are in trouble:

(click to enlarge)

You can also see this information globally for the whole project, in My Office > My Assigned Projects, and compare it with your other projects:

(click to enlarge)

Reporting on performance

At reporting time, you can produce reports by client. For example, you might want to see all billable time for the last month for the client:

(click to enlarge)

Or, you might want to see a list of all incomplete tasks that are over budget:

(click to enlarge)

Billing the client for extras

Time reports are great to extract billable time information. You get all the information: the person who did the hours, on which task they worked, and when they did the work. Once you have that report, you can simply send it directly to the client with your invoice.

(click to enlarge)

How do you do it?

How do you manage client-focused projects? Add a comment or send me an email at karine.simard@aceproject.com.

I'm in charge of both sales and marketing at Websystems. This is highly irregular: at most companies, sales and marketing are kept separate.

However, in a small company like us, it makes more sense to have one person do both sales and marketing. Since our business is online, I can do live demos and write a press release in the same day. I like to keep contact with our potential customers, because it keeps me connected to what people are looking for in a project management system.

It's very important for marketers to know what their audience is looking for. And it's very important for the sales team to understand well how marketing wants to present the product. 

At Websystems, having both sales and marketing in the same person is beneficial. I get good contact with the market, and I can align my campaigns with current and upcoming trends.

It's easy to get swallowed by project management tools. It's easy to feel that we can get all the information we need from a piece of software.

But it's not true. 

If you want to know how well a project is going, take your team to lunch. They will tell you more about the project than any statistic. While you're sitting at the table with your team, take a look at their non-verbal behavior. Are they happy to be together? Are they talking to each other? Are they just sitting there, waiting for lunch to end?

How your team interacts together will show if they are getting along and where there might be personality clashes. Moreover, the general mood of the team is a good indicator of the project's status.

We've published an article on PM Hut, one of the web's leading blogs on project management: 10 Signs That You Should Give Up on Your Project

It outlines my ten things to look out for in failing projects. I hope you enjoy it!

About PM Hut

PM Hut currently is highly praised in top Project Management blogs, and has the best Project Managers in the world as contributors http://www.pmhut.com/project-management-authors for a list of all contributors). PM Hut is currently the #1 Project Management Blog on blogged.com: http://www.blogged.com/search/project%20management.

I've been studying to get my PMP certification this fall. The interesting thing about studying for the PMP exam is that good project managers will naturally go through most of the processes, so there aren't so many new concepts to grasp. However, there is a LOT of theory and terminology to learn!

We are entering out third and last cycle of development for AceProject 4.6. So far, the agile method has been working well, and we think AceProject 4.6 will benefit greatly from shorter iterative development cycles.

Today, I want to show you three really nice improvements we've made to AceProject.

No need to close the task to save your changes

We were getting a lot of comments from our users about the inability to just Save a task in AceProject. Before 4.6, you need to navigate to another tab or close the task in order to save your changes. It was annoying and a waste of time.

Well, not anymore!  We've added a new option to the Update button: Update + Keep Open.

Documents go public

Another request we had from our user was about documents, that it woul be nice to permit some documents to be seen by people outside their AceProject team. We thought that was a great idea!

Now, AceProject task and project documents can be public. When a document is public, anyone who has the link to that document can see it, without the need to log in to AceProject. This is a great feature if you want to show your client a screen mock-up, for example. 

You'll know when you can start the work

With AceProject 4.6, when your tasks are controlled by a dependency link, AceProject will tell you when you can start working on them. You won't need to check if the predecessors are completed, AceProject will do it for you and send you an email like this:

Expect AceProject 4.6 for Christmas

We're starting out last development iteration today. Our goal is to make it available in December for online accounts, and early 2009 for the Source Code package.

I do a lot of presentations in my job: product demos and user training fall under my responsibility. I love it, because it's never the same. Each client is different, so I adapt my show based on their needs.

I almost never use PowerPoint.

Why never use PowerPoint?

PowerPoint is too easy to abuse. When you abuse PowerPoint, it poisons your audience. PowerPoint poisoning is not pretty: people's eyes glaze over, some fall asleep, many will start doodling on their meeting agendas or fiddling with their phones.

PowerPoint abuse happens when people put what they will say in the slides. When they give the presentation, they read their slides.

The problem with this is redundancy. The human eye can read much faster than the human mouth can speak. So, by the time you even start reading the slide, your audience has already finished reading it. What interest should they have in you? All the information is right there on the screen, in the hand-out.

And that's exactly when PowerPoint poisoning begins.

The presenter talks and no one listens. Her voice becomes part of the background noise. Attendees feel that they are wasting their time, listening to a presenter who reads her slides. The presenter realizes no one is paying attention to her anymore. She gets nervous. She loses her motivation.

In the end, it would have been faster to just give everyone the PowerPoint file and leave.

10 rules to prevent PowerPoint poisoning

1. The slides should support your point, not repeat it.
2. Pictures are good.
   
3. Handouts are good - people like to take notes.
4. Questions are good - your audience should be part of the presentation.
5. What you say goes in the notes for the PowerPoint.
6. If you need to read it, it doesn't belong in a PowerPoint presentation. It belongs in the handout.
7. No more than 6 lines of text in one slide.
8. No more than 6 words per line.
9. No type smaller than 20 point.
10. No feature lists - save it for the brochure.
    

I'm sure most of you have had this situation when they deliver a product:

Situation 1: What the client wants and what the client asks for are two different things

Client: It's really nice, but that's not what I wanted

Supplier: This product was built to meet the specifications you gave us.

Client: Yes, but that not what I want.

Supplier: ...

Situation 2: What the client needs and what the client asks for are two different things

Client: This product is great, but it's not doing what I need it to do.

Supplier: We built the product you wanted.

Client: I know, but it turns out I need the product to do something different

Supplier: ???

What do you do?

Now, you end up with a dilemma in these situations: should you rebuild the product so it does what the client wants/needs, at you cost, or at their cost?

After all, you built a product to meet their specs, and it's not your fault if it's not what they really wanted.

Or is it?

What should you have done?

As the project manager, you should have made sure you understood what the client wanted, needed, not just what they were asking for.

See, the problem is clients often approach us with a solution: I want X feature added to your standard system. However, if you dig deeper, you'll find out what they really need is something else.

Here are some questions to ask your clients:

• What do you want? - This question is easy enough to answer for them. Most of the time, you'll know what they want from the get go. Getting the specifics of what they want might be a little trickier, though.
• What the problem are you trying to solve? - This is harder to understand. The best way to get this answer is to have the person show you. 
• What do you need? - The difficulty in this question is to get a precise answer.

Here's an example:

Client: I want a new report in AceProject.

Supplier: OK, why do you want this report? (what's the problem?)

Client: Your Time Report gives me all the weeks one by one, I just want a total for the whole period.

Supplier: OK, and what do you need the new report to do?

Client: Well, I would like the report to give me monthly totals for each project, and email it to all my project manageers automatically.

Supplier: OK, so you want a monthly time report of all the actual time worked on each project, that is produced automatically every first of the month, and emailed to any user with Project Manager access to at least one project?

Client: No! I want each PM to get the data only for their projects, not everyone else's!

Supplier: OK, let me send you a detailed scope of work and a mock-up before we get started on the quote.

It's detective work

It's not easy to get what the client needs, wants, and asks for. But if you don't do it from the get go, you'll end up spending a lot of time redoing your work.

A while ago we went grocery shopping at a different shop than our usual place. It's surprising how we get used to a specific customer experience.

Long story short, we were confronted with rules that seemed illogical in the purchasing of apples. It made our experience at this store negative, and we are very unlikely to shop there again.

A few days later, we bought more apples from our regular store, and the experience seemed even better, because of the frustration we experienced at the other store.

Which apples do you think were eaten first?

We kept looking at the "apples of frustration" and just didn't want to eat them. The apples themselves were fine, but the memory of buying them was so negative that it spilled on the product.

In the end, we ate those apples, but not before all the other options were exhausted.

Do you want to be that choice?

How people interact with you influences how they see your product. If their experience with your organization is good, they will see your product favorably, maybe even better than on the product's merit alone. Inversely, if your customer's experience with you is frustrating, they will feel that frustration every time they use your product, even if the product in itself is fine.

How we treat customers is something we should strive to keep as positive as possible. The payback is high, and lasts a long time.

All the boss wants is to know how the project is going. She's not interested in the task specifics. She wants to know if the project is on track or not.

Of course, who manages just one project these days? You need to be able to show all your projects together.

2 little reports will do the trick for you: the Project Gantt Chart and a customized Projects list.

Start with the Projects list. 

Go to My Office > My Projects > My Assigned Projects.

This page shows all the projects you're assigned to.  You can customize the look of this list to show computed fields like Actual Hours and Estimated Hours.

I suggest you choose these fields:

This will give you a nice report that you can simply print or export to Excel:

A Projects report like this takes 5 seconds to make - you won't need to reset the columns once you've done it. It's dynamic, so the data is always up-to-date. It tells you instantly how on budget or off budget you are.

And now for the Gantt

For bosses who want it even simpler and more visual, go for the project Gantt chart. Go to Administration Light > Gantt Charts > Project Weekly View. Each project is shown as a bar, so it takes about one second to see which projects are on track and which are in trouble:

And now you're done

Put these two reports in an email, print them, insert them in a PowerPoint presentation. It took you about 5 minutes, and you can go back to managing the project.

Do you have a plan in case something goes wrong in your project?

Let's say a key team member accepts a position at another company. Are you prepared to reallocate her tasks to someone else? Is there someone else who could take over?

Or, let's say the 5 more people that human resources were to hire for your team take longer than expected. Will your project still be on time without them? What are you going to do: overwork the people that are there, negotiate a new deadline?

It's not about being pessimistic, but about being prepared. About knowing where the project could be endangered and thinking about how you're going to deal with that.

Often, we don't want to think about those risks, because we are confident that we will succeed, and because we don't want to "jinx" it. But not planning ahead your risk management strategy is playing with fire. With risk management, you will be able to deal with potentially disastrous issues better, because you thought of what to do beforehand, not in the heat of the moment.

This week, I had finally had enough. There was no apology that could fix the relationship, no reparations possible. It broke my heart but I had to do it.

I broke up with a product I love.

Xobni is a great Outlook Add-on that indexes all your email, provides neat metrics (like response times) and had a highly usable search interface. I had been using Xobni for months.

Xobni had only one problem: it slowed down not only outlook, but my whole computer. At first I didn't want to admit it: I blamed it on the anti-virus software, then I did numerous registry cleaning sweeps, all to no avail.

So even though I love Xobni and I love using it, I just can't take the slow-downs anymore.

It's not me, it's Xobni

When I uninstalled it, Xobni asked me if I wanted to know when performance issues were fixed.  So Xobni knew there problem was on its end, and it admitted to it.

Now I am eagerly waiting for an email, hoping that I can reconcile with my beloved product.

Where did it go wrong?

I'm not on Xobni's development team. However, I've spent a bit of time on their forums, trying to know the cause (and hopefully the solution) of my problems. What I read was a lot of people writing to say how they loved Xobni and how sad they were that they had to uninstall it. Every once in a while, someone from Xobni's support team would pipe in, asking people to add their antivirus info to the support thread, and suggesting that people clean up their windows registry.

As time passed, the ratio of people who were able to fix their performance issues VS people who had uninstall Xobni changed. There were more and more people removing Xobni. It seems Xobni's development team is having a hard time fixing the performance problem, and users are running out of patience. 

It's that simple: the collective patience of users who believe in the product is running out.

Back to normal, and I hate it

Now I have a fast computer. But I have to make do with Outlook's search engine. I'm unhappy about that, but at least I'm not spending time waiting for my computer.

Tomorrow: How to prevent your customers from breaking up with you

This fall is exceptionnally lively, politically speaking. There are elections both in the USA and in Canada. While in the USA there are only two political parties, in Canada there are five major political parties:

• The conservatives
• The liberals
• The socialists
• The greens
  
• A regional party that represents the interests of the Quebec province

That means 5 political programs. Five documents any elector should read before making a decision. That's a lot of information!

This situation is an excellent example people making decisions based on their intuition instead of facts. Of course, there are some facts involved - the facts we read or hear about in the news or on political advertisements. But on voting day, it will all come down to guts: how we feel about the candidates, about the parties, and who we trust most.

The truth is, we could make a complicated comparative chart of all five parties' programs and study it carefully, in the voting booth we would still choose with our gut.

What is failure? 

 Dictionary.com defines failure as:

Basically, failure is either the absence of success or the state of something that does not meet expectations.  Can a project fail if expectations were not clearly stated at the beginning? Or if its criteria for success were not defined?

Success can happen outside of expectations

Sometimes the expectations we have at the beginning of the project become irrelevant as the project evolves. For example, a research project where the initial expectation of is to develop a drug to treat a specific condition, but that drug ends up as a better, more effective treatment for another health problem. Can this project be seen as a failure? There is still success, even though the end product does not meet the initial expectations.

Success and failure are in the eyes of the beholder

Some projects go well. Some projects go badly. At the end of the project, a lot is forgotten, and what is seen is the end result. So even if it was excruciatingly difficult to deliver, the project can still be seen as a success if the end result is seen as positive.

Having patience in today's world is waiting more than 5 minutes for your latte at the coffee shop without throwing a tantrum.

Seth Godin's article about patience and success is food for thought.

Like anything else in life, projects are an investment in time. It doesn't matter how fast someone wants the project to be completed, things take time and, short of a time machine, time itself cannot be sped up.

Not every delay problem can be solved by throwing more people at it. If you need 100 boxes moved from room 1 to room 2, having more people moving the boxes will get the job done faster. However, there are only a few tasks that really gain speed from adding people on the team.

Writing the documentation for a product, for example, cannot be sped up by adding more people on the team. If you get several writers working on the same document, all you'll get is a patched-up user's manual that looks not quite put together. The cost in quality is not worth the savings in time.

At Websystems, when we work on a new version of AceProject, it's ready when it's ready. We avoid delivery dates for AceProject because we prefer to release a product that works well to releasing a product on a schedule. It's harder to be patient towards the end, when all I want is to show off the new shiny version with all the cool features, but in the end it's worth it, because when I do get to show off the new AceProject, it works.

Project management is all about data: goals, requirements, resources, tasks, documents, planning, scheduling, budgeting, and then some.

No matter how much of that data one can product or study, there is always a time when the decision must be taken with the gut. When we must listen to the voice of intuition.

When, even with all the facts against him, a developer can be convinced he can fix the problem within the deadline.

Can you trust intuition?

Intuition and faith and so much alike. Can we trust somebody's gut feeling, or even our own? Especially when it contradicts the facts?

The fact is, if we don't, chances are we will regret it down the line. When someone is absolutely convinced, and can pass this conviction onto the team, they deserve to be given the chance to prove their gut feeling.

It's a big risk.

But one will never be great by playing it safe.

So the question is: would you prefer greatness or safety?

We see them all the time on the web: cool tools. Websites that offer a service that is original, technically advanced, or just fun. If you read a lot of blogs, you probably check out at least one of those cool tools every week. How many of those make the move from cool new tool to tools you use regularly?

There are three reasons why you won't keep using a cool tool:

   1. It's not usable enough
   2. It's not fitted for what you do 

Not usable enough: I want Sandy

I wanted to use this service. It's really cool. It's an automated assistant that you can email back and forth with, to build lists, keep track of appointments and receive reminders. Somehow I never could master the Sandy's syntax. I tried a few times, couldn't get Sandy to do what I wanted, and I gave up.

Not fitted to what I do: Cymbolism

This is another very cool service. You search for a word, like powerful, and cymbolism returns a chart with the colors people said they associated with that word. I really enjoyed adding my vote or color associations with words, I and also really liked researching words and looking at the colors that were associated with those words. Unfortunately, I'm not a designer. Although this cool tool is a great reference for graphic design, it's just not for me.

Usable and useful: GMarks

• It's very easy to use: you save the bookmark to GMarks the same way as you would a regular bookmark.
• It's very useful: not only can I synchronize my bookmarks across several computers, but I can get my bookmarks even if I'm in an Internet café halfway across the world from home.

What about you?

How about your cool tool? Are people coming back to it, again and again? Which one do you use?

In project management and in management in general, the word resource is seen often. According to Wikipedia, a resource is any physical or virtual entity of limited availability, or anything used to help one earn a living.  This includes:

• Space: meeting rooms, offices
• Furniture: desk, chair
• Equipment: computer, tools
• Humans: people, coworkers

How can one put people in a list of resources? A person is not a resource, she is a person. She cannot be reserved, allocated and definitely should not be sold or bought. She cannot be stored until you need her again.

Treating your teams just like your material resources dehumanizes. A human is not something you need to accomplish a goal. A human is the reason why your organization exists: to provide goods and/or services to other humans.

Humans should be more than numbers and work-hours that can be contributed.  Humans are the foundation of any company. They should be recognized as such.

At Websystems, we have IP phones that forward our voicemail messages to our email addresses. This is very convenient, since we can forward the message to the appropriate person easily. The voicemail notification also contains any special information entered by the caller, such as confidential or urgent.

Naturally, when I saw a voicemail marked urgent in my inbox, I listened to it right away. It could be a client with a problem that is keeping his team from working.

It wasn’t.

About 20 seconds into the message, I realized the call was not an emergency; it was a sales pitch, for an outsourced sales call service. I immediately stopped listening to the message and deleted it.

My only regret is that I didn’t catch the product’s name. If I had, I would have made sure I never buy that product or any product from that company.

Leaving a fake urgent message to make sure I listen to it is disrespectful. It’s bad salesmanship. While it did get me to listen to the message, it had the opposite effect. It convinced me never to buy the very product he was trying to sell.

You get only one chance to make a good first impression.

He blew it. This salesperson blew it for his product and his whole company. If he had left me a regular voicemail message, I would have called back, if only to let him know whether we are interested in the product. It’s the decent thing to do.

The first contact with a potential client is so crucial. The impression they will get of your company and your product will be shaped by the way they feel they are treated on that first contact.

Guess who’s the first contact? Sales. Sales is one of the most important parts of the customer service team. They should be held up to the same standards of respect, courtesy and integrity as the rest of the company.

I am presently working on a glossary of terms related to project management. As I was looking for definitions of time management, I found this interesting comment on Wikipedia:

"In a 2001 interview^[2], David Allen observed:

You can't manage time, it just is. So "time management" is a mislabeled problem, which has little chance of being an effective approach. What you really manage is your activity during time, and defining outcomes and physical actions required is the core process required to manage what you do."

Yet another thing to ponder. Time goes by at a constant speed, regardless of how we feel about or what we are doing. 

But what can we do?

Everyone can make the best of their time. In a project, it's important to wonder if those 4-hour meetings are really an efficient use of the team's time (they're not). We shouldn't think about managing our time, but about using our time efficiently.

• Is it more efficient to research a problem for several hours on Google or to ask your colleagues about the solution? 
• Is it more efficient to update your AceProject tasks with the latest info, or to tell each person individually about it?
• Is it more efficient to email everyone a document and manage comments in the email replies, or to send them the link to the document, and have them type their comments directly in the project management system?

If the project lasts long enough, you can bet the deliverables for the project will be modified. Here are 3 common things that will affect the deliverables:

• Adding a feature to the product
• Changing requirements
• Adding another stakeholder

New features

• How much more sales this feature will bring
• How much time will the feature take to develop
• How the new feature will affect everything else in the product

If the cost of adding the feature (the time and complexity added to the project) is higher than is impact on revenue, it would be a good idea to understand better why the feature must be added. Even more so if the project schedule is already tight and the delivery date cannot be moved. Unless your team has a time machine or a crystal ball, this could spell disaster for your product and project.

New requirements

Just like features, requirements tend to be modified along the way by changing needs. Instead of great ideas, the situation is more of the we-didn't-think-of-this type.

First of all, if your organization makes a habit of we-didn't-think-of-this, project managers should make a point of being extra careful with requirements documents. Adding an operating system to a software requirements documents, for example, can seriously impact the project.

Just like new features, before accepting the new requirement, it's imperative that one evaluates the cost VS benefit brought by this requirement.

New stakeholders

New stakeholders carry the highest risk on your project deliverable and the project itself. Every person has their own way of doing things, and they will want their opinions and methods to be included in the process. The only problem being, the process is already under way.

Instead of trying to shove the new guy aside, it's worth the time to explore what they bring to the table. They would not be added to the project for now reason (or so  one would hope).  By being open to the stakeholder, you may be able to reconcile the methods already in place with his methods, or at least negotiate an compromise that gives your project a chance of success.

Being open is hard

When things are started, it's hard to change course. No one likes to reevaluate decisions that have already been made. But the reality is, life changes all the time. If there is one thing you can be sure about your project, it's that something new will pop: new requirements, new features, new people, new deliverables altogether.

If you are open to this possibility, you may find inspiration and motivation in tackling these changes in your projects.

Interface design is an intriguing and widely diverse world. There are as many ways to make a text box as there are designers on the planet.

I like getting to a site and seeing a new, original way to design a web site's navigation. However, I cannot stand interfaces that confuse me.

Here are the two most confusing types:

• There are so many buttons, links, and other gizmos trying to grab my attention that I cannot choose where I should go next.
• The design metaphor is so obscure I can't even find where to click next. 

Those pages feel like no one outside the design team saw them before they were published. It's as if the design team spent so much time tweaking and refining their work, they lost sight of the reason for the page's existence. 

That doesn't mean a web page or system interface can't have a lot going on. It must be clear what's the next step. When on gets to AceProject's web page, they see this:

There are a lot of links in there, and a lot of text. However, the most prominent buttons in the page say STEP 1, STEP 2, STEP 3. It's obvious we want you to try the demo first, then create a free account, then purchase a subscription. 

The best design is not the most beautiful

The best design is the most effective. It gets people to do what you want them to do.

Websystems is located in Quebec City. This year, it's the 400th anniversary of the city's foundation. While technically, Quebec City is not the oldest city in North America, it is the only one that is still there, in its original location. 

To celebrate the event, we've been having a big party since the summer began. Yesterday, we had one of the biggest events so far: the event organizers invited Paul McCartney (yes, THE Paul McCartney). The show was free. You can imagine the crowd that showed up to see this living legend. People slept in front of the gates before the park opened. about 1 person out of 3 that lives in Quebec City went to the event.

That's how much pull Paul McCartney has. How powerful his brand is.

What I found interesting about him is that he seems to have built his brand on just being himself. People like him because he is a legend in the musical realm. But he's likeable because he seems to be such a nice guy.

That can't be faked or built. 

When testing a new product interface, we at Websystems have our ears out for comments that sound like "it's complicated" or "I can't figure out how to do this."

For us, when these comments are made repeatedly about a feature or a page in AceProject, it means we've made a mistake in our design. While we work hard on getting good, usable documentation for AceProject, our goal is that our users don't need to consult it when building their projects, updating their tasks, and going about their daily activities in the system. We think is filling out a time sheet should be self-evident.

Moreover, even if it's really difficult for the developer, he will work on making that feature simple and easy for the user once. The user, on the other hand, will use the feature many, many times. So it's more profitable to invest development time once, since it will save a lot of user time in the long run.

Last year, we were contact by our local university to participate in a business development mission to India. We would sponsor a graduate student of marketing, who would go to India on our behalf. We could set any business development goals we wanted. The mission was presented as a good way to learn about this huge market and how we could adapt AceProject to increase sales in India.

We figured this was a great opportunity. After all, India is poised to become one of the biggest economies on the planet. Its growth has been above 6% every year in the last decade. This is a market where we definitely want to be.

We would learn more about India. In fact, we thought, why not actually hire someone in India to do our customer service and sales? We knew one reason why our sales are not spectacular in Asia is the time zone difference.

Hence, we tasked our representative for the mission to not meet with a project management association, explore the feasibility of hiring someone in India to work for us directly, and meet with some of our existing clients.

Before take-off: it doesn't look good

Vanessa, our representative for this mission, found challenges even before landing in India. She had a hard time contacting companies by email and phone. In order to call India during the daytime there, she would have to make her calls in the middle of the night. There were very few responses to Vanessa's emails, and the responses arrived several weeks after her sending the initial message.

We were still excited about sending Vanessa to India: it would be a great opportunity to learn about doing business in this country.

On site: we are far from home

As our representative Vanessa, wrote in her emails, India is so different from North America it's stupefying. On the practical level, even in the cities, neither electricity nor Internet access are reliable. Power outages are frequent. In office buildings, they may have generators and be able to maintain power during the outages. Still, the availability of the Internet cannot be relied upon. This would make hiring someone to work from home pretty much impossible.

Hiring someone from a call center would seem like a better option, but with a 30% turnover rate, it would mean having someone new every few month, and we would spend too much time training the person, only to see her move one to another company and have to start over (again).

Moreover, in India, social contact is very important. It's important to meet a representative for the product they want to buy. It's important to them to develop a relationship with their suppliers. Connections and contacts play a very important role in the way business is conducted. For us being so far away, it makes it hard to establish this type of meaningful contact with our clients in India.

Back home: next steps

If hiring someone to work at home won't work, and "renting" someone from a call center will be too unstable, what should we do? 

Our first goal is to improve our availability to our Asian customers, so that they can call someone during their normal business hours. Hiring someone closer to Asia (in Europe, for example), might be easier to manage. The time zone difference is shorter, and the work / business culture is closer to Canada's. It would seem like a good compromise.

The opinion one will form of a product will be different along the life of the product. Let's take the example of software.

When you do the first installation, everything is fresh and it feels like the system work perfectly. Once you upgrade (to a new version, for example), you will see the full measure of the product's quality. When upgrading to a new version, the process should be smooth. I am not talking here about an absence of bugs in the system. What I mean is that the system should be able to take the previous version's data (configuration, preferences, etc), and fit them in the new system.

If that process is not smooth - as happened with one of the tools we use at Websystems - you loose the trust of your customers, and they will prefer to stick with the version they have, even if the upgrade brings more usability. If the hassle of the upgrade is too much, there will be an impact on subsequent sales to existing customers.

In project management, it's easy to confuse urgent with important. When something is urgent, it's usually assumed it must be important. No true. The fact that a specific report is needed in five minutes for the board meeting does not necessarily need it's important. Maybe the meeting can go on without the report.

Since the word urgent makes everyone run a little faster, its vulnerability to abuse - as we discussed already - requires more scrutiny. 

When dealing with an emergency, one should answer the following questions:

• Can the project work around it?
• Can the project be completed without it?

 If the task can be late and not affect other tasks immediately, then it is not urgent, even though it could be important. Also, is the project can live without that task being completed at all, it's not even important. However, if the task both stops the project dead in its tracks and is required for completion, then it's both urgent and important.

Better get right to it, then :-) 

Do you consider customer service a "cost of doing business?"

In your organization, is sales at the top of the food chain, and customer service at the bottom? 

How's that working for you?

The sales team will talk to your client up and until the initial sale is made. Afterwards, the most contacts your client will have will be with your customer service and technical support teams.  Once someone is your client, the 'cost' of getting more business from them is much smaller than the initial sale. Your customer service team can make this sale. In fact, since their position is one to help the client, it's even easier for them to upsell that client.

Your customer service and technical support should be treated as heroes. Their job is to save clients from their problems and to improve your company's image in their minds. If your customer service teams feel empowered and valuable to the organization, they will do a much better job winning back unhappy clients and upselling the happy ones.

Investing in customer service pays off

Anyone that interacts with customers is an investment. All customer-facing employees represent your organization in the mind of the client. How you consider them affects how they treat the client, and that affect what your client thinks of your organization.

Before you join a project, before you even start planning it, it's important to take a moment to make sure it's worth the effort you're about to put into it.

What is the goal of the project?

Is the goal of this project clear? Do you know what your deliverables are? Are the requirements for the project spelled out and agreed upon by all involved?

If the goal, the deliverables and the requirements are not clear yet, the project is not ready. If you start something with a foggy idea of what needs to be done, that project already has serious problems.

Can it be done?

Are the goals, deliverables and requirements even attainable? If you cannot be convinced, in your heart, that you can pull it off, you should not take on the project. If you can't believe in the project, it's not use working on it: you've already set yourself up for failure.

Does the organization really need that project?     

Is this a single-client, once-in-a-lifetime project? Is it vital for the survival of the organization? Will it improve the organization's offering/product/opportunities significantly?

There has to be something to gain from successfully completing the project. 

Is this project profitable?

It's not just about the money. The question is, what is the organization looking to get out of that project? Is it increased revenues, increased market share, increased credibility in the market? 

Once this is figured out, you should know if this project will be profitable. You need to decide what will come out of the project is worth if the effort, time and investment required to make this project a success. It's important to get more out of the project than you will put in.