The first key issue I see is the lack of clearly defined projects at the executive level. We get vague outlines of the project. No clearly defined objectives or wants are laid out. With this comes the lack of prioritizing the projects. To many times I see a new vague project that comes out and it has to be done now. All other projects must be put on hold. What this does is to prevent the projects put on hold to actually come to fruition. When the vague project is started, scope creep sets in. Since it was not clearly defined, new ideas and wants get added in while the project is being worked. Some call this Agile development. Agile development is not adding in changes while the project is being worked. Agile development is small iterations that go through a full software development cycle. Each iteration is clearly defined and each iteration is a final release with minimal bugs. The iteration might not have all the functionality for a final release but the goal is to have a release that works. Again Agile development is not continually putting in changes while the project is being worked.

The second key issue I see is the lack of getting the whole team involved in developing the plans for the project. There is simply no way one man will know what is involved in completing a project. A team must be formed to construct the work needed to complete the project. This team might need more people to break down the work into manageable tasks. Only by involving all the resources can you get a concise break down of the work needed. If you do not get the team together to go over the work, tasks can and often will be missed. Some tasks might seem simple and be glossed over. That simple tasks might not be so simple. Interdependencies between tasks can be missed. Some tasks need other tasks to be completed first before it can be done. And finally there can be a lack of clarity on role responsibilities and task deadlines unless the whole team is involved in the work break down structure.

These two key issues are what I see all the time in my current work environment. Both of these two issues can be resolved by clear communication and educating people on there necessities in the project. Projects must be clearly defined. The work break down structure must have the team’s involvement to get all tasks needed to complete the project.

Items needed:

1. Activity List
2. Activity Attributes
3. Resource Availability schedule
4. Project Management Plan

There are several tool and techniques that one can use to do the estimating. Most have been discussed before. Two that are important is Expert Judgment and Bottom-up estimating. People with knowledge in resource planning and estimating can provide the expertise needed for this phase. It would also help if the experts also worked on similar projects. Bottom-up estimating is breaking down the work to the smallest levels. The resource needs for each of the detailed work is estimated and the aggregated into a total figure.

What should we get out of this exercise in estimating? We should have identified and described the types and quantities of resources required for each component in the WBS. This means that each activity will have the necessary items scheduled to complete that activity. If an activity does not have the necessary resources to complete the activity you have not completed this phase. When the estimating is done, updates to activity attributes and resource calendars will be an output. A resource breakdown structure will be created from this phase. The RBS is a hierarchical structure that lists the identified resources by category and type. A final output of this phase is changes. Resources might not be available when needed for the planned activity. Changes might be needed for the activity. These changes will need to be reviewed by the Integrated Change Control process.

A Guide to the Project Management Body of Knowledge, Third Edition, PMBOK Guide. Project Management Institute, Inc. Pennsylvania, 2004.

It is amazing some of the ideas that come out of the marketing department. Ideas come out and start to get implemented without any thought to whether it will sell or not. There are lots of ways to see if the product will sell. What does your customer base want from your company? Are other companies having success with the same product? Was there a survey done to see if people want the product? Is the product linked to some specific business strategy? Without some support from marketing to show how the product will improve the bottom line, it will not get the support it needs as it is being developed. This means the project will be stopped short of completion.

When all the envisioned products are put in a line, how do you choose which one to work on? There might be a hundred product ideas but you have only enough resources to work on five of the ideas. Each department will want their ideas at the top of the list. In many companies, politics plays more of role on projects than business strategy. Sometimes the most profitable project is put at the end of the list because the department head is not in good graces with the President of the company.

Most projects are given deadlines from senior management. Some of these deadlines are so unrealistic that the project will always be in trouble. Deadlines can only be made once all the facts are in. You should get all the experts in a room to define deliverables and approximate times, only then can an approximate deadline be given.

Sometimes projects are so vague there is no clear definition on what it is. Projects must have clear and precise characteristics. Only by clearly defining a project can it be a success. Deliverables must be measurable to ensure clear paths to completion. Vague deliverables leaves projects susceptible to scope creep. Customers will never be satisfied because there was no clear picture of the product before the project started.

A project fails because:

1. The project is not linked to a specific business strategy.
2. The product does not have the support it needs from the beginning.
3. Department heads are not in agreement on the right path for the company.
4. Deadlines are unrealistic.
5. Product is vague on the requirements for success.

1. Project Scope Statement
2. Activity list
3. Activity attributes
4. Milestone list
5. Approved change request

Activity sequencing uses several tools and techniques to complete its task. The activity list must be organized into a logical order. Precedence must be determined to ensure some activities are done before or after other activities. By setting up a proper sequence, we can create a realistic and feasible project schedule.

Precedence diagramming method (PDM) is one of the tools used in activity sequencing. PDM constructs a project schedule network diagram that uses boxes to represent activities and connects them with arrows to show dependency (PMBOK 132). These boxes are called nodes so the precedence diagramming method is also called activity on node (AON). This is the most common method. The PDN uses four types of precedence.

1. Finish to start – the activity can not begin until the previous activity is complete.
2. Finish to finish – the activity can not finish until the previous activity is finished.
3. Start to start – the activity can not start until the previous activity has started.
4. Start to finish – the activity can not finish until the previous activity has started.

The finish to start is the most common type of precedence, and the start to finish is hardly ever used.

The arrow diagramming method (ADM) is another tool. The ADM uses arrows to represent activities and connects them with boxes or nodes to show their dependency. This is the opposite of the precedence diagramming method. The arrow diagramming method is also known as the activity on arrow (AOA). The ADM only uses the finish to start type of precedence. The ADM can also use dummy relationships to show logical relationships. The dummy relationship is shown as a dotted line on the ADM. Since the dummy relationship is not an actual activity, the duration is zero. The duration is the time it takes to complete an activity. The dummy relationship has no “work” so no duration.

Schedule network templates are just that - templates. They are standardized project schedule network diagram templates that are used to expedite the preparation of activities. They can be used to show such items as floors in a building or the startup phase for a development project. When the activities are going to be the same, use a template.

One activity might be dependent on another activity. You will use the different types of precedence to describe the dependencies. In the dependencies, there might be a need to have a lead or a lag between activities. An activity might be pouring cement; however you must wait two days after it is poured before you can remove the cast around the cement. This two day wait is a lag. A lead allows the next activity to start before the previous one is finished. A lag directs the next activity to wait even if the previous activity is done.

When you are finished with activity sequencing you should have a project schedule network diagram, an updated activity list, an updated activity attributes list, and the requested changes that were revealed when setting up the diagram.

Part 1 of Series “Project Time Management”

A Guide to the Project Management Body of Knowledge, Third Edition, PMBOK Guide. Project Management Institute, Inc. Pennsylvania, 2004.

I am all for making a buck, but this seemed a little strange. You offer an application for free and everyone can use it for commercial purposes. Instead of just selling support you also sell the license for the software if they want support. There is nothing written on the web site for support that says you have to buy a license for the software. It really makes you think about what Sun is doing, not to mention that the license for the software is six times as much as for the support.

So, Sun gets you to use the free software for your business. You get dependent on the software for your business. You get to a certain point and realize that you need support to continue your business without any hiccups. Now you realize that you can have support after you dole out large amounts of money to buy the software they said you could use for free. What do you think they are going to do with MySQL? They just bought MySQL, but MySQL is also free. You can buy support for MySQL. They do not require you to purchase licenses for MySQL in order to buy support. Now that Sun has purchased MySQL, are they going to use the same process they use on SJAS? Are they now going to make a customer buy licenses for MySQL in order to buy support while still offering MySQL for free? I am not sure but it doesn’t look good to me.

Maybe I should look at JBoss and PostgreSQL.

There are plenty of other articles ranging from agile development to leadership. Each is educational and engaging. I highly recommend reading it.