in

User Community

MAKING IT IN THE BIG WORLD OF PROJECT MANAGEMENT.

Go Ahead, Manage

The life of a small company in the great world of project management software: from marketing to product management, software development... and project management, of course.

Subscribe to this blog by Email or add it to your RSS feeds

February 2008 - Posts

  • Meeting clients

    We are back from a 3-day trip to Seattle, where we met our client, AT&T.

    It is so refreshing to meet clients face-to-face! With a web-based business and communications at the level they are now, we tend to forget how much more we can get out of meeting with someone in person. There is so much to learn from someone's non-verbal communication: attitude. facial expressions and reactions, gestures, etc.

    Now that we have met the team we work with at AT&T, we have a better understanding of who they are as persons, and this will help us serve them better. We have a feeling that wen now them as persons, and so do they. When we talk and email, we'll be able to imagine the person we are talking to. 

    Meeting clients puts the human back in customer relations. 


     

     

  • Project management: democracy, autocracy or dictatorship?

    Who makes decisions in your project management team? Do you have a dictator, a group of decision-makers, or does eveyrone on the project participate in the decisions?

    Democratic project teams: the quicksand trap

    Taking everybody's opinion into account is a great idea, it opens up new avenues of thinking. It's good for creativity and solving problems. However, if decisions are put to a vote, there is always the risk of taking the wrong decision, because not everyone in the group has a 360-degree view of the problem. For example, if the team is composed of a majority of developers and only one person who represents the interests of the clients, should the client representative's vote weight heavier in the balance?

    Another issue with democratic decision-making is the quicksand effect: discussions can end in a stalemate. Where does the team go from there?

    Autocracy: distribute blame, dilute merit

    This is project management by committee, where only a select few take the decisions, not the whole team. While this decision-making style can be more proactive than a democratic style, it is style vulnerable to stalling.

    An advantage of autocratic ruling is that the decision committee usually includes all stakeholders, so decisions are taken with all the facts in hand, and everyone usually understands them. However, it has the disadvantage of distributing blame, so bad decisions are less traceable; and diluting merit, so good ones are not traceable either.

    Dictatorship: I leader, You team 

    Dictatorship is as great (or as bad) as the dictator. When the project lead knows how to listen to her team and accepts suggestions, she can be quick and effective, taking important decisions when they are needed and keeping the project going smoothly. Unfortunately, when the project leader is a certified ---hole, she can turn any project into a miserable failure.

    With dictators, there is always the risk of more distance between the leader and her team. If she spends too much time being a leader and not enough time being part of a team, it may affect the cooperation that she gets from her team.

    It all comes down to the humans

    Regardless of the decision-making style your organization privileges,  they are as good (or as bad) as the humans taking them.

    At AceProject, our style is democratic, with our benevolent dictator having the last word :-)

     

     

     

     

     

  • Marketing and making sense

    It seems to me marketing is about convincing people to buy a product. In so doing, should it not tell people something that makes sense?

    Especially in business-to-business marketing, I don't want to insult my reader's intelligence by telling them a bunch of nonsense. Do they really care about how great I think my product is? Maybe they do.

    I think what they care about is what my product can do for them, for real. How much time will they save? How much more money could they make? How much easier will their life be with the product?

    I understand that it may be difficult to make precise statements in reply to those questions. But in the end, that's what most of us want: more time, more money, less difficulty.  Which translates in more happiness.

    I firmly believe we can market products concisely, clearly, without resorting to complicated statements.

    Marketing should make sense.


  • Project management and time management

    It seems to me that, while one can manage his/her time outside of a project, it would be difficult to manage a project without managing time.

    I could not imagine a project with a set of tasks, and no dates.  How can one plan without time references?

    On the other end of that spectrum, if a project is late, can it still be considered successful? In some industries, being late is part of the deal, it's normal and expected. However, in other businesses, being late mean penalties and a tarnished reputation.

    So, what is the most important: doing it right, or doing it on time? 

    My position here would be both. It's no use delivering something on time, if it's not fully completed and functionnal. There is nothing worse for a comapny's reputation than a beta-level product released. Clients will forgive lateness to a certain extent, but they will not forgive and product that doesn't work.

    However, there is a limit to a client's patience. Sometimes, when trying no to make it right, but to make it perfect, we miss the window of opportunity for the product. Either another company beats you to market, or the need for the product has disappeared. Just think of the company trying to develop the perfect BETA tape...

    We have to do it right, and not too late.  

     

  • How do you choose which features to include?

    As any software development company will tell you, there are always more features to add to a version than there is time to implement them correctly. Hence, we face a challenge: implement more features with limited functionnality, or implement fewer features will full functionality.

    It may be tempting to implement as many features as possible: spread-sheet product assessments and feature comparisons would proudly bear the YES checkmark next to all the lines in the requirement list. However, being able to say "yes, we have reports" quickly followed by the limitations of the feature is no way to win your prospective client's heart. As they use the feature, they will quickly realize that, although the feature is there, it is stripped-down and not what he or she expected.

    I believe that if we are going to implement a new feature, not only should it work, but it should also be complete. It should have all the functionnality that is expected. If you can import user data, you should be able to import all user data, not just the user name and password.

    The end result is a piece of software that is truly usable, that clients will enjoy using.

    So, how to choose, then?

    This is the difficult question. How do we choose to implement a feature over another?  There is the what the market wants, what the users want, what the developers want, and what the boss wants. Who wins?

    With AceProject, we keep an updated wishlist where we record how many times a specific feature has been requested. When we get ready to start working on a new version, we look at the file and choose what we will include. It's a good way to stay up-to-date with what our clients want and at the same time, get a bigger picture view of what people ask to add or change in AceProject.

    Once we've chosen which requested features to add in the new version, we discuss what we would like to add to make our system kick butt, so AceProject is not only user-driven, but remains the brainchild of our President.

    A team effort

    AceProject's development is very much a team effort. Our users are a big part of AceProject's team, and their suggestions never fall on deaf ears.

     

  • Effort is not always proportional to value

    Sometimes, that new feature that took so much time and effort, that was so complicated to implement, is not important to the client. This can be heartbreaking for developers.

    I've seen it often: my press release is sent for approval, and the project manager comes to me, asking why the new feature is not mentioned in the release. I see disapointment in his eyes. After all, they worked really hard to make it work. All that effort should translate into a killer feature that customers will flock to, right?

    Not always. Sometimes the effort translates into something that is taken for granted by the client. Sometimes, the little-worked-on feature turns out to be the big selling point for a product.

    The case of the one-client feature 

    There was this product launch where the development team had implemented a very complex algorithm in the product, at the express request of a client. The client himself was very pleased with the algorithm. However, he was the only one in the market to use it: this client was such a pionneer in his field, no one else was ready to implement that kind of reporting.  And so our development team felt like they worked hard for nothing.

    About this they were wrong. Their work was worth it. The client who adopted this feature was one of the biggest accounts in the company. Unfortunately, it did not have the right appeal for the market at the time. So it was left out of the press release.

    The case of the feature taken for granted

    It may be really complicated to develop something, but it has nothing to do with its perceived value by the client. Sometimes the work that goes behind a simple button goes unrecognized. Or sometimes, the market simply expects this feature to be in the basic system, and is not willing to buy a product solely based on that feature.

    Case in point: Task dependencies. Task dependencies were a tough cookie to implement in AceProject. Our development team worked really hard, for a long time, to make it work. However, for our clients, it's only normal that we support task dependencies. How hard we worked on it had not effect on the value of that feature to our users.

    The case of the widely popular feature

    Sometimes, the opposite happens: this one feature, that was very easy to implement, turns out to be a key selling point for the software. 

    A few years back, a developer on the team had time left from his debugging schedule, so he decided to clean up the code for a file import feature. It made such a difference for the users! We were able to sell more copies because importing files from our competitor's system worked smoothly. This was amazing to the developer: to him, it was just a few hours of improving some code. For the users, it was a time-saver.

    The lesson to be learned

    As the title says, effort and value are not equal, simply because the effort involved in accomplishing something is not always perceivable to the client. However, internally, we should recognize the effort, even if it's not the star feature. After all, if the "taken for granted" features were not there, we would have no software to sell.

     

     

  • The Defining Moment

    I imagine every company has a moment like this, where its founder decides to take a leap of faith. Faith in himself, the product, and the promise of success.

    For Websystems and project management software, this moment happened in the Fall of 2001. Back then, Daniel worked out of his two-bedroom appartment, and AceProject was called FreeTaskManager. 

    Daniel and I met when we both worked at Multitel, and lost our jobs in the post-9/11, dotcom crash layoffs. I was a technical marketing coordinator and he was a software developer. Daniel had put together AceProject's predecessor, FreeTaskManager, and I was working with him on the interface terminology and documentation.

    So it was that we both ended up jobless. The logical course of action would be to look for another job, and keep FreeTaskManager as a sideline. Or was it?

    This is when the leap of faith happened. As we were working on FreeTaskManager, Daniel stopped, thinking. He said:

    "Karine, do you believe in FreeTaskManager? Do you think I should focus on growing my business, instead of looking for a job?"

    This was not difficult to answer at all. FreeTaskManager was awesome. I already believed in FreeTaskManager. And I said exactly this to Daniel. No doubt he asked this question to many persons around him before taking his decision - Daniel is not the impulsive type. But once his mind is made, he will stick to his guns.

    And here we are, seven years later. AceProject is, according to Alexa, the third most visited site related to project management software. We are now a bigger team, and we are still working on making online project management software that rocks. 

     

     

     

     

     

     

     The story of Websystems: from sideline to full-time gig to employees and having an office

  • Welcome to the First Post

    Hello everyone!

    It's finally here: AceProject's community site. Not just a blog, but a user forum too. Not only do we get to talk to you, you get to talk back as well.

    A Blog
    In AceProject's blog, we will talk about everything from project management, software development, product management to marketing in a Web 2.0 world. In essence, we want to talk about our life as a small team making it in the great big industry of project management.

    We will also have product announcements, where we  will let you know what's brewing at Websystems.

    A user forum
    The forum is for you. What do you like most about AceProject? What do you dislike about AceProject? How would you like to see the system evolve?

    More than that, it's a good way for all of us (users and creators alike) to get to know each other and share our experience and knowledge. 

    Tell us what you think!
    We are looking forward to hearing from you. Don't hesitate to drop us a note

    About Websystems
    Websystems is the creator of AceProject. Founded in 2001 in Quebec City, Canada, Websystems is a true child of the Internet age. All our products and systems are online. Every time we release a new feature, it is based upon our customers' requests and needs. We like hear your ideas because, after all, you are the project managers and we are the software developers.

    For us at Websystems, it's a great opportunity to have this new tool to talk to you, and hear from you.

    I hope you enjoy it!



    Karine Simard
    Marketing and Customer Relations
    Websystems, Inc.
    support@aceproject.com
    Posted Feb 12 2008, 10:00 AM by admin with no comments
    Filed under:
Copyright © 2001-2008 Websystems Inc.