Project management has changed: the specialized field full of buzzwords, and tightly dominated by Microsoft Office (a stand-along, 1990's application) came to an end when the Internet world discovered online project management software and its immense benefits.
In this article, I will highlight some of the (many) reasons why web based project management is better, especially when applied to online projects.
Time estimates are always 100% wrong.
The amount of time that a task will take only has one possible answer: "As long as it takes you to do it". Any time estimate is always a wild guess -- or worse, a guess that will tend to be over-optimistic in order to keep the customer happy. This is especially true in projects that require either programming or design skills. Time estimate for tasks is the biggest downfall of classic project management: some tasks (not many) will take a fraction of the forecast time, whereas other tasks (most of them) will take a lot longer than the longest, most pessimistic forecast. Definitely longer than the customer would have ever accepted when they signed the formal requirements document. Time estimate being so bogus is a major problem for classic project management, where these estimates, along with duration, are used to create charts which will give you nice theoretical reports of the "best path to completion" -- reports which most of the time remain theory (or, "wishful thinking").
Formal requirement are just not useful
In classic project management people spend phenomenal amounts of time getting the "requirements" document ready. The requirements list become a binding document, where (at least in theory) everybody is happy with what the system will do: the customer is happy about the feature they will get, and the company is happy about the amount of development time that will result in. These documents take weeks, sometimes months to be discussed (time that could be used to actually get development done). Sometimes time-consuming meetings are held, where the customer insists on discussing minute details while team members know that those details will be completely meaningless by the time the project is actually implemented. The main problems are:
Requirement documents get old very quickly. In many industries (like software development, electronics, or even product development), technology advances very quickly. A set of requirements that was fine 18 months ago (9 months to get the requirements right, and 9 months of project development) is likely to fail the market completely -- and that's while the project is still being actively developed. You might be designing a desktop application, and discover the that world is going online; or you might be designing the best soy milk maker, while the craze for soy milk is been and gone -- suddenly, your soy milk maker needs to also make almond milk, and tofu, and the requirements -- you probably guessed it -- need to change.
Requirement documents are invariably ambiguous. It doesn't matter how long you spend on your requirements document: there will always be a sizable number of ambiguous items which will erupt in a fierce argument with the customer (especially while the project is running late and over budget due to badly-guessed time estimates.
Team members never work alone on a task
As much as you'd like to live in a world where task 1 is going to be completed by person A and task 2 is going to be completed by person B, the reality is that a task needs to be bounced off between team members, each one contributing to it in some way, before the task is actually marked as completed.
This goes against the methodology of classic project management, where a task has a set resource allocated to it. Again, it's the usual "wishful thinking" view which plagues classic project management, and that in the end brings projects, schedules and budgets to their knees.
Not always better
Having written so much about why online project management is better, I feel the need to present a counter-argument as well: there are cases where online project management is not the best choice. For example:
You know in advance how long a task will take. This seems like a dream to a programmer, but in actual fact several industries out there have this luxury. An experienced brick layer will tell you exactly what time they will be finished laying bricks. The weather might get in the way, but if a job is started, it's started and it will be finished within the specified time frame.
Task dependencies are really strict, and must be enforced. In online project management, task dependency seems to be implied or completely unavailable (although some software out there does allow them). However, some industries do have very strict dependencies -- try to put a roof up if the bricks haven't been laid yet! If your project has very strict dependencies which are a big part of your project, then maybe online software management won't work for you.
You know exactly who will be able to complete tasks. Again, in some cases there are tasks that can only be completed by a specific team member and "bouncing a task off" is not even a possibility. Again, if you are building a house, only the brick layer will be able to complete the task "Lay bricks". He or she might look for a replacement, but in the end you won't be able to bounce the task off to each other, and get the cabinet maker or the tiler to lay bricks. So how do we get our staff these awesome project management skills and also allow our customers to get the proper training on our project management software? We believe in software customer training. It is what makes us different and sets us apart from our competitors.
In some industries, collaboration is just not useful. While in building a web site, designers, coders, clients and managers need to communicate. However, in something like construction, the bricklayer will never want to talk to anybody else other than the manager. If schedule shuffling happens, it needs to be carefully negotiated with each trades person by the project manager.
In the end, it's up to you to decide the best solution for you: the key is to keep things simple, and make sure you focus on getting things done the right way.
- Project management: web (main article)
- Product requirements (279 words)
- Issues with requirements (251 words)
- Documenting and verifying requirements (462 words)
- How estimation is done (343 words)
- Estimations (291 words)
- Software requirements (145 words)
- Alternatives to project management (130 words)
- Using learning management systems to train up PM staff (150 words)
- Organization of software requirements (84 words)
(C) Copyright 2009-2016. Copying of this site text is forbidden