I remember that first term paper I had to write when I was in school. It seemed so long! How could I ever have 20 pages to say about any subject? I felt overwhelmed by the size of the task. I think the teacher saw the same look of discouragement on all our faces, so she gave us a hint: make your table of contents first.

When I sat down to make my paper's table of contents, I realized I wasn't going to write 20 pages on the same subject: I was going to write 4 4-page sections on different aspects of the same subject. This was much easier to deal with, in terms of planning my work and feeling more in control of the paper.

The same happens when I have a huge project to work with. For example, with the release of AceProject 4.5, which is almost ready, we had to plan for documentation, promotional material, web site updates, email blasts, etc. Taken together without any structure, I felt like there was too […]

Vague deliverables make everyone unhappy. They create misunderstandings and
unfulfilled expectations. They tarnish reputations. 

Projects should always have clear deliverables. Too often, the project's deliverables
are so vague that no one can agree that the project is complete.

Take software development for example. If the project's deliverable is the
new version of that software, the project manager should be able to spell out
exactly what constitutes the new version. Is it the Beta version? The Release
Candidate? The Gold Master? The first client installation?

Moreover, it should be clear who accepts the deliverables. Should the
development team decide when they're done? Should QA sign off on the new version?
Should management, sales or customer service have a say in it?

Without a clear deliverable, there's the inevitable gap between what the
project team thinks they should deliver, and what the project's client
expects. 

But how can one get a clear deliverable from the project client? Often, the
project's client, be it management, the market or an actual client, has a hard
time expressing what they want precisely.  It's up to the project manager
to provide a clear deliverables list on which both […]

Do you remember the last time you shopped for a car? As you get in the
dealership, you start looking at cars in the showroom. A salesperson helps you
out, answering your questions and guiding your choice for a new car. Once
you've decided what you wanted, the pressure is applied.  As you are
sitting at the salesman's desk, you hear the fatal question: "What would
it take for you to buy this car today?"

Why? Why would I need to buy the car today? If the car is so great, and the deal
I'm offered is so good, why can't I sleep on it? Or shop around some more?

The answer is in how much confidence the salesperson has in the
product.  If the sales person has enough confidence in their product and
the deal they have for you, they will have no problem wishing you a good day
and waiting for you to return to buy the car. If the confidence isn't there,
they will want to seal the deal as soon as possible, before you have the time
to change you mind.

You will see these […]

No one likes to fail. No one likes to admit that they went wrong. That's why
sometimes we keep trudging on with a doomed project for a long time, before we
finally accept that it has failed.

We can see this more clearly with software and product development: the
product launch keeps getting pushed back, the features included in the product
keep getting reduced.  Development teams seem to be spending more time
fixing the product that building it. On the human side, the people working on
the product are no longer proud to say they are on the team. They start looking
more like prisoners than professionals.

The excuses start flying. It's nobody's fault if the product is late.
Marketing says it's the development team's fault for not building a good product;
development points the finger back at marketing for ever-changing requirements.

The fact is, no one wants to hear that the project has failed. It's not
failing right now. It failed a few weeks (or months, or years) ago, but no one
wanted to hear it. And now the organization is stuck with a very big money […]

Sometimes you end up with a little more in your plate than you would like. Do you ever get that feeling that you're about to forget something?

It's like you're juggling with too many balls and it's only a matter of time before you drop one. Only, when what we're dealing with is projects, the consequences of dropping something can translate in dollars for your company.

When this happens to me, I start having problems sleeping at night. I wake up in the middle of the night, and turn on my computer to make sure I have not forgotten something. It's no way to get a decent night's sleep, and it makes for a grumpy marketing girl the next morning. 

So, how can we keep control or a long work list? How can we make sure nothing is forgotten and everything is done on time? 

Sure, the good old excel sheet will work well to make a simple list. But I find with Excel sheets, I just keep reprinting it everyday, to make sure it's up-to-date. I end […]

There is no shortage of articles about the importance of customer
service.  Last week, Guy
Kawasaki published an interview with Bill Price,  titled "Why The
Best Service is No Service. Bill Price's premise is that products should work
so well and be so easy to use; clients never have to contact customer service.

I agree completely. Our clients should not have to contact us to understand
how the product works. It should be self-evident from the get go. Documentation
should be readily available to help the client along.

The only problem with this philosophy is that nothing is ever perfect.
Products sometimes have flaws. Clients sometimes use the product in a way that
was unforeseen by its creator. Even though AceProject is an Internet-based
company, our clients still like to talk to us, and get a feel of who we are in
the offline world.

Hence our customer service rules at AceProject: 

1. Humans speak to humans
   No one should have to find their way through a automated system, or talk
   to a machine. When people call […]

Do you take decisions based on a hunch, or do you take the time
to analyze everything carefully?

In project management, your type of decision-making can
profoundly affect the rhythm of the project. Even more, your team's
decision-making style can also affect the project.

For example, I am an intuitive decision maker. I will focus
on a few parameters, and take my decision on how I feel about the situation more than on what the data says.  Daniel, on the other hand, analyzes all
aspects of the situation. He likes to sleep on it. Daniel wants to make sure we
make the right decision.

When Daniel and I work together, we are very complimentary.
While I will become very enthusiastic and come up quickly with ideas and
solutions on how to address a situation, Daniel will calm me down and take the
time to think about every solution that I proposed. While I can to push Daniel
a little bit to make a decision at times, he will keep me from running with an
idea without thinking about its consequences.

Whether you are intuitive or analytical, you must be careful
to […]

It seems product development – like project management in my opinion –
requires adjustment from the theory of it (or its planning) and its reality
(how things actually happen.

Case in point:

Last year, before we closed for the holidays, we sent a nice email to every
AceProject user, thanking them for their business and wishing them a merry
Christmas and happy new year. The intention behind the email was good. We just
wanted to send good wishes to all the good people who made AceProject the
success that it is today.

However, we did not think this through. We sent the email to every user
of AceProject, not just the account administrators. Usually, when we send a
email to AceProject users, we only contact the account administrator. 

While we had some very nice email replies and warm wishes from our user
community, we had some very unhappy customers as a result as well. Some of our
clients are using AceProject to keep in contact with their clients. They have
customized AceProject with their logo and company name. To their clients, it
looks as if they are using an in-house project […]

Ron, from Digital Creations, in Louisville, Kentucky, is using AceProject in a very interesting way.

Ron does not outsource his work, but he does feel the need to keep his clients in the loop. With AceProject, he can let his clients know exactly how far along the wedding video editing is, and even let them see how many hours is has worked on their video, up to date.

Ron explains it all in this blog post.

For Ron, AceProject is a great customer service tool. He uses AceProject to let his clients peek in on his work and to automatically notify them when he's beginning work on a new film sequence. Ron and his newlywed clients can even exchange documents, ask questions and provide feedback right in the system.

Now that is outstanding customer service! 

If you'te in the Louisville area and planning your wedding, be sure to check ou Ron's services.

In many ways, a project is like a relationship. It starts out shiny and new
and exciting, a lot of time and effort is invested in it, and when it has run
its course, it leaves no one indifferent. Just like relationships, there are 5
main ways to deal with the end of a project.

Say it ain't so!

You liked that project so much, you don't want it to finish. Or, uncertainty
about the next project makes you want to stretch out this one. In any case, you
start looking to unfinished business, insignificant details to keep working on
the project.

Get over it. There are many more exciting projects in your future, and you
can only sart them by letting go of this one. 

Thank God it's over

Not all projects go well, even with the best team and the best intentions.
When a hellish project comes to a close, the first thing most of us want to do
is forger about it. Never speak of it again. If we could erase any record of
the project ever existing, we would.

Get it over with. The more you […]