Random Thoughts from a CTO: Project Management

Is No News REALLY Good News?

Fri, 04 Aug 2006 15:42:09 GMT

"No news is good news". This phrase is spoken throughout organizations across the world. It is said by managers and non-managers alike for the following reasons:

You are a project manager and expect that the team is empowered to make good decisions. Therefore, any news that gets escalated to them is usually bad news that they must help with.
You are on a project team and anticipate some issues that the team must deal with, however nothing has been communicated. Instead of checking into it, you are hopeful (ok, perhaps wishful) that everything must be ok.
You are a project stakeholder and haven't heard from anybody on the project team for some time. You haven't heard of any problems or delays so you assume that the team must be doing alright and will deliver on time, within budget and meet expectations on the deliverables.
As a member of the project team, you don't want to look bad in front of the others. You know that you aren't going to meet your deadlines, but don't want others to know. You adhere to the "don't ask, don't tell" policy - your project manager hasn't asked if things are going wrong (assuming that no news is good news) so you won't tell him or her otherwise. Through heroics, you will work extra hours and do "whatever it takes" to get it done even though it is a long shot.
As a functional manager, your recent new hire has had little experience with the technology the project team is developing with nor the processes that they are doing their work. This person has had some training and initial orientation through HR, but is now on their first project. You haven't interacted with this person very much, but assume that they must be busy and productive since they haven't asked for either your help or help from co-workers.

All of these have something in common - the lack of good communication, follow-through and accountability.

In scenario #1, the manager has good intentions because they don't want to micro-manage and trust the team to do their jobs. However, by saying "no news is good news", are they also discouraging good news to be communicated? If the team is ahead of schedule or had made some great discovery, shouldn't this information be shared? The project manager should make it clear to the team of what their role is - to provide information to the stakeholders on progress of the project and to remove any roadblocks the team is having. It is important that the project manager ask good periodic questions to the team on both progress and issues. Still let them do their work, but pick up on signals that things aren't going well and address them either to the team or the particular individuals. Encourage the team that the key is good communication for the entire success of the team. There are no good guys or bad guys, just the team trying to get things done together. This should take care of scenarios #2-#4.

With scenario #5, a new hire, it is a good practice by a manager to "manage by walking around and asking plenty of questions". In this scenario, the manager should observe from afar - not over the shoulder, but periodically just check in and see how they are doing. There are plenty of signs that should help you determine - their work area, the tone in their voice, how focused (or unfocused) they seem to be. You can also ask casual questions with co-workers, project team members and project manager - "How's Joe coming along?" "Is he having any difficulty meeting deadlines?" "Does his work have good quality?" You will either run into two situations: 1) The new person is doing very well and the "no news is truly good news", or 2) The new person doesn't want to look bad, or isn't a good communicator, and doesn't ask for help. In the latter situation, as a manager you need to let this person know that it is ok to get help. If they aren't a good communicator, you may want to check in more periodically using the technique above.

So, is "No News is Good News" a bad practice? Not entirely, if you have a person who is experienced, provides quality work, self-motivated, takes initiative, and a great communicator -- those are the attributes that you can make the assumption that no news is ok. However, you should probably change it to "News, whether Good or Bad, is better than no news at all" in order to better communcate your motives with using this statement. This changes the focus to communicate, over-communicate if necessary, to ensure that everybody is on the same page and processing the information together as a team!

Are you focused on what's really important on a project?

Thu, 03 Aug 2006 15:16:45 GMT

If you ask a typical project manager, the goal of any project is to ensure that the project is done on time and budget (which includes labor and non-labor costs). If you ask a functional manager, he or she will say the goal of any project is to follow quality standards and processes and to meet or beat certain measures in the organization for quality, productivity and efficiency. If you ask a team member of a project, they will probably provide answers such as "feel that my work counts", "do something new or interesting", "make sure that my stuff works".

But, is anybody asking the end user? What would be their goal? I believe it is safe to say that their goal would be something like this -- "To provide a solution that resolves any existing problems and improves upon their current situation better than other alternatives - manual or automated." With this solution, they probably want it as quick as possible but also want to make sure that the end result does not impact them in a negative way - bugs, hard to learn, too complicated, too many additional costs with not as much benefit, etc. These goals should satisfy the functional manager because it means that they need to be thinking about quality, productivity and efficiency.

I cringe when I hear a story published that the project manager was proud that he or she was able to get a long term project on time and within budget. But, what does that mean exactly?

Did the end solution meet all of the specifications determined up front?

Did the project team consist of the same people that worked reasonable hours on the project?

Did the project have no risks that occured or did those risks not impact the scope, cost and schedule?

Did the schedule accounts for all tasks and issues that weren't planned up front in the project?

Did the project not allow for scope change or involvement from the customer?

I would guess that the answer to all of these questions would be "NO". Therefore, cost, schedule and scope all did change from the beginning of the project until it's end. Therefore, why is there such a big deal to make sure that the project hits the date and costs? If these changes are happening, then the end user should be a part of those changes, and should see that things are changing all of the time. With that said, isn't hitting a schedule and budget on target just coincidence? That for some reason, all of the stars aligned just right and you happen to meet those goals. Sure, there are financial and other pressures to meet schedule committments that have been made ahead of time. However, does it really matter if you hit those dates and meet those financial goals if what you produce doesn't really help the end customer? Wouldn't you be more successful if you just waited until you have something that is worth sending out the door?

Next time you do a project, make sure the entire team (management included) puts less focus on hitting dates and budgets and more focus on what the ultimate goal of the project should be - to meet the goals of the end users. Make sure that end users are involved throughout the project. Make sure that they see progress along the way and can react to how the end product is coming along. And, utlimately make sure that the solution that is provided at the end of the project meets or exceed their expectations.

Then, you can publish and brag about how successful your project was for the right reasons!

Just because the project is over, does not mean it is done!

Thu, 22 Jun 2006 17:14:03 GMT

For those that don't understand technology and software engineering, there is an expectation that once a project has been completed that it is truly done. They also expect that there is a quick transition from development into production and are ready to move on to the next big thing.

For those that do understand, they realize that things are just beginning especially if you are introducing new technology, product or functionality that the company and customers have not used before. Why is there such a disconnect and how do you narrow the gap to ensure that enough attention is given to ensure the long term stability of both the technology and solution?

Here are some of the issues that are faced:

Customer changes - Customers can be fickle and have the right to change their minds. The challenge is to determine why they are changing their minds. Did their business change? Did we miss the mark on the functionality? Did we resolve the true problems or just some of the symptoms? Even with the best upfront requirements and design processes, there will still be changes in requirements as long as their are people who want to change their minds or their business.

Industry changes - You need to constantly be monitoring the industries that you serve. In this world of mergers, acquistions and consolidation, things can change quickly in an industry. If you were serving only a segment of a market, you can see that segment disappear quickly. Watch how you competitors are addressing the changes. Watch how other vendors are adapting. And make sure you are following suit.

Operational adjustments - Though you try to accommodate business operations of your customers as you develop solutions, sometimes the technology itself may require some changes in how your customers run their business and train their staff. Take, for instance, the first time that your customer might have used a mouse for a GUI application instead of just using a keyboard. That took some adjustments in how they interacted with the system (as well as knowing how to trouble mouse operations). These adjustments can also take place within your organization. Your sales people need to understand these new technologies and how to sell them to customers. Your technical support people need to understand how they work and when they can break so they can more effectively troubleshoot (and help prevent) customer problems.

Training adjustments - After customers start to apply and use the new technology and solutions, you will discover that they may be using it differently than expected, or that the information that you have provided isn't detailed enough.

Defect corrections - No matter how much testing that is applied, either inhouse or in the field through beta testing, problems will be found by customers. Hopefully, these problems are minor or cosmetic in nature, in which case you have more time to address. Otherwise, if they are more critical, you need the time to address the fixes.

Operating System changes - Unless you are using an older OS, you are well aware of how often the operating system changes - either with major new revisions or through minor fixes. Many of these minor changes have to do with hardware changes, security patches, or product stablity -- all are usually important to fix at some point. With major OS changes, there may be things that aren't backwards compatible, so you may have to change your products to support both new and older versions. If the changes are significant enough, you may decide to not support older versions of the OS at some point.

Hardware changes - Hardware changes at a tremendous rate, not just the main PC (server or workstation), but other peripherals - printers, pointing devices, keyboards, USB devices. Just like operating systems, there are major changes as well as patch releases to consider. Also, you need to consider how many kinds of printers you are going to support and "certify" through testing. And, you may need to consider when products are no longer supported either because they are obsolete or the technology is too old to be compatible with later technology.

Software Tool changes - This is an area that gets the least amount of exposure, mainly because it is not easily seen within the product or by customers. All of the infrastructure to build and support the product goes through changes - programming languages, development tools, database vendor like with hardware and operating systems. As these pieces change, the same decsions need to be made as you did with hardware and operating systems including the need to move technical tools to other platforms.

So what can you do to account for these changes in your product development?

Add tasks in your product development projects for changes - Where the changes can still apply to the general scope of those projects, you should account for changes in those projects.
Create product maintenance projects - Where there are a lot of smaller changes that relate to your products that can be grouped together in a project (and don't related to the scope of projects in the previous point), you should create separate maintenance projects to address the changes.
Create infrastructure projects - Where the changes aren't directly related to the development or maintenance of your products (such as operating system changes), you should create separate projects to address and incorporate the changes.
Educate customers and other non-technical people - Talk to your customers and others about the costs of incorporating new technology or solutions, both short-term (projects) as well as long-term (maintenance). The better they understand both the value of these changes (long term stability, better security, improve ease of use, etc.) as well as the costs mentioned above, the easier it will be to support the new technology and solutions in the future.

Your Box of Constraints

Mon, 19 Jun 2006 23:14:28 GMT

Wouldn't it be great in your personal life if you had unlimited resources - unlimited personal time, unlimited money, unlimited space to hold everything that you buy? Don't think about that too long, because unless your last name is Trump or Hilton, most of us have constraints. We have to work, we have checking accounts with limited money, and therefore have constraints about what we do and what we buy in our personal lives.

The same holds true in our professional lives. For this discussion, I'm going to expand projects to be defined as a "series of tasks" in order to include as many of you as possible. As we are performing those tasks, we don't have the "blank check" to do whatever we would like to do. Sometimes the ideal way of performing those tasks isn't realistic. So what is reality you ask? It is defining the tasks that you perform based on particular constraints that exist within a business. The better you understand these constraints, the more realistic you will be in implementing those tasks. By defining the "round hole" using these constraints, you won't put frustrated later in trying (and wasting your time) to place your "square peg" into the round hole.

These constraints form the box that surrounds your project:

Time - We don't have all the time in the world. There are only so many hours in a day, week, month. There are times we need to take a vacation, training or end up being sick. Plus, there is an expectation from the customer that things should be done in a reasonable time. What is reasonable time? You will need to determine but you must not exceed it.
Budget - Most larger projects have a budget of what can be spent both labor and non-labor costs (equipment, training, travel, food, etc.).   If your project doesn't, at least your company has a budget to follow. Budgets can be broken if reasonable, but you need to get approval from the project stakeholders. There usally is some wiggle room but not much. There is NO project worth breaking the bank (unless you are a startup and the project is to develop the product or service you are to offer and you won't make money until you have it ready).
Skills - Even if you come up with a great idea, you may not have (or can obtain) the people with the right domain expertise to pull it off - either from the business or technical side (or both). You must determine who you have available and whether they can accomplish the goals. If they cannot, you should at least postpone the project until you have available resources.   If the people have some skills, you should allow for rampup time either on the job or through training until they get up to speed.
Dependencies - Some projects stand on their own, but many are dependent on either concurrent projects or future ones. You must understand those dependencies and make sure that everything is falling into place. Many people focus too closely at the project at hand, and accept when dates change but don't realize the impact to other projects. This is particular important when you are working on a project with a third party.
Customers - If customers cannot use the results of your effort, you have failed. You must understand what your audience is capable of learning and make sure that your solution is both usable and simple enough for them to get it.   If you have a highly technical and educated customer, you might be able to provide more complexity, bells and whistles. You must understand the breadth of customers you have in order to meet the most of their needs.
Competition - You have to keep an eye out on competitors and what they are doing. If they decide to change direction, you might have to as well.   You need to be careful that you are tracking what the industry is doing and not just following suit (and thus producing something that is just as worthless to you as your competitor). You don't control what you competitor does, but you may need to react to them in order to maintain a competitive advantage.
Quality - You can't put out junk, you also cannot guarantee 100% quality (or zero defect in our arena - software). You must determine what level of quality is acceptable for each project and make sure that everybody involved in the project achieves that goal (not just the testers or the beta customers).
Technology - Technology may not be ready to accomplish the goals that you have or they are too expensive because of costs or instablility.   You also need to factor in that some technology may be changing at a pace that is faster than your product, and that by the end of your project there are significant changes. You can't let that happen, and need to allow for adjustments (i.e. upgrades or integration) throughout the project.
Risks - Risks are inherent to any project. It is important to identify those risks as early as possible in the project, their probably and impact, and what contingency plans you have when the risk occurs. Even with all of that, you may be taking on more risks than you can afford and asking for trouble along the way. Understand with the stakeholders how much risk is too much and when to postpone (or even cancel) a project when that is the case.
Need - If you haven't prioritized your projects and tasks based on customer need and value, stop right now and do so. Even if you are sure you are working on the highest need and value at the time, customers are either fickle or situations change that could cause other work to take priority. Monitor that during the project and allow for a certain amount of change. If there is a chance that needs will change more quickly, shorten the size of project to accommodate. There is nothing worse than having a team of people half way through a project and have them change gears. Find ways to avoid that situation.
Resources - Resources aren't just people, but space, equipment, communications, training and other things needed on the project. Even if you have the money to add more people to the project, you may not have the space for them. You may not have the space to set up a complete testing environment and will need to rethink what is possible with your given space. Understand what your limits are and whether or not you can "outsource" them.

If you are a project manager, make sure you are considering and asking the right questions to determine what these constraints are and how you addressing them in the project. If you a team member or working on projects by yourself, make sure you have a clear understanding on these constraints from your manager before implementing your tasks. There are no absolutes or ideals on projects, there are many compromises you must make by balancing these various constraints. However, compromise in this case doesn't have to be a bad thing, in that you are trying to accommodate the best of all situations in order to meet the most needs. If you find you are on a project where there is too much compromise and nobody will be satisfied, you should seriously consider cancelling the project because it may be doomed from the start.

The right way to start a project

Wed, 14 Jun 2006 15:43:57 GMT

Alistar Cockburn came up with a deliverable as part of his Agile methodology called Crystal Clear that I believe can be helpful for any kind of project, especially within software development. He calls it a "Mission Statement with Tradeoff Priorities" document. Here's his definition of it:

"The mission statement is a brief description, typically a paragraph to a page, of what is to be built, its purpose in a larger context, and the project's priorities in sequence, from the most critical to those that can be sacrificed.

It is produced by the project stakeholders with the help of a project manager before the project starts or during project chartering. It is reviewed and referenced by everyone on the team. Any major change in the mission statement triggers a team meeting, so that everyone one the team understands the new mission.

A good mission statement retains its clarity and relevance over time, keeping the work efforts focussed on the most important features of the system.

Because people can generally only protect one and possibly two project priorities, it has no more than two top priority items. The mission statement makes clear to the team what can be sacrificed if necessary to preserve the top priorities."

Following is what we came up with for one of our projects. This list can (and probably should) be different for every project and you don't necessarily have to use the attributes listed below. These were the ones that we felt best reflect the needs of this particular project. Since we have done this, we have had excellent discussions between the project team and the stakeholders on how project decisions impact each of these attributes and to remind the team what has been decided by the stakeholders. It keeps us consistent and honest about what is possible and important for the project. It also shows that you can't have it all, but compromises must be made. This document defines those compromises. Give this a try on your next project and let me know what you think about the results!

-------

With every project, there are several priorities to be considered throughout the duration of the project. As decisions are made by the project team and approved by stakeholders, there may be conflict between some of the priorities. The following priorities for this project have been identified in sequence, from the most critical to those than can be sacrificed.

They fall into three categories:

Sacrifice these last – these are the highest priorities and should not be compromised on this project.
Retain these if at all possible – there may be exceptions, but try to maintain these priorities unless they conflict with the priorities in the highest group.
Sacrifice these first – These priorities are more considerations than requirements, where possible try to keep these unless they conflict with any priority in the higher groups.

Sacrifice these last:

Time to market – Getting this product out to our customer base as quickly as possible is desired, with an expectation to demonstrate this functionality at future trade shows.

Accuracy & quality – Making sure that this product meets our company's standards of quality and the data presented and stored is accurate.

Retain these if at all possible:

Integrity of Existing Applications – This application will not break any existing applications and will consider all outstanding bugs and enhancement requests during the process.

Ease of use – Application is more efficient and convenient to the end user than other methods.

Ease of learning – Easy to understand and doesn’t require extensive end user training.

Execution speed – Works as efficient as possible with the minimum hardware requirements, also gets tasks done as quickly as possible.

Ease of maintenance – Designed and developed in ways that can minimize costly maintenance long-term.

Low cost to customers – Developing a product that doesn’t require license fees or other costs to pass to the customer; which in turn, maximizes our sales and support margins.

Sacrifice these first:

Quantity – Focus on developing as many functions as possible with no regard to the other priorities.

Flexibility – Developing a product with every possible function in order to completely meet the needs of every customer.

Portability – Ability to provide this application on other operating system platforms or hardware devices such as a handheld.

Low cost to develop – Develop using tools that don’t have frequent, costly updates to maintain; which in turn, maximizes our sales and support margins.

Storage mechanism – Ability to develop this product so that the storage mechanism (e.g. database) can be migrated easily if necessary.

Bad Estimating Processes

Fri, 26 May 2006 15:31:36 GMT

Estimates are a vital part to ensure that each project is done on time and within budget. Over the years, I have seen various patterns of estimators out there -- here are the top 5 ones that you don't want to have on any project followed by their remedy. Here are the processes that I believe some people use that as a project manager you need to recognize and correct the behavior:

The "Padder" - "No matter what I believe my estimates are, I'm going to add a fudge factor to it!". This is what you would hear from this pattern. This kind of estimator will take risks and uncertainty into their own hands instead of getting the project manager involved. People who do this usually don't trust their historical estimates. What's worse is that the project manager if they don't see this may also end up adding to the estimates, thus "double-dipping" -- causing estimates that are way overstated. Remedy: Make sure that this kind of estimator has the opportunity to identify risks, questions and other things that cause the uncertainty. Also, show how past estimates from this person were padded and make sure that they trust their estimates.
The "Utopian" - "If everything goes right, my estimates will be correct". This kind of estimator looks at every task as half full, and isn't willing to accept that there are risks. Remedy: Murphy's law is always in effect, and it is the job of the project manager to uncover every rock and bring to light any risks.
The "Pessimist" - Polar opposite of the Utopia, and worse than the "Padder". This person will determine every single scenario that could occur on every task and take the very worst scenario. Remedy: It's the project manager's job to remove risks and other obstacles during a project, so they need to make sure that these kinds of estimators bring those issues up with plans to remove those issues prior to the actual tasks.
The "Back Filler" or "Make My Date" - "We have pre-determined dates anyway for every project right? So, I'm going to make sure my estimates hit that date regardless if its accurate. If I was wrong in my estimates, I'll just work more time in order to hit the date." Though it is tempting by both project manager and team members to make the project schedule hit the date, this is the wrong approach in doing so. Any time I have seen this pattern, I have seen those people work a lot of overtime and they usually still miss their dates because they dramatically cut their estimates because of an unrealistic date. Remedy: No matter how much pressure you get from project stakeholders to hit a date, educate them on the importance of understanding the scope of the work first, then adding resources or cutting scope in order to hit a particular date. Make sure that the team members understand the importance of their estimates through this process.
The "Generalist" - "I'll give you a rough idea though high-level estimates, but I can't guarantee any more details than that." This kind of pattern indicates that the estimator either doesn't trust the process, doesn't know how to estimate, or is the results of poor requirements and design in understanding the scope of the project. Remedy: Make sure that each person that is required to estimate truly understands the scope of the project. Through a Work Breakdown Structure (WBS), show how the estimator can break down their tasks in order to better understand what they are going to do on the project. With better details of how they will do the work, will come better estimates. Also, make sure that they don't feel penalized later on the project as discoveries are made, that the schedule will adjust as necessary for changes. Through this, they will trust the process.

Your Project Rights

Mon, 22 May 2006 21:24:10 GMT

Extreme Programming (XP) has as part of its methodology the concept of rights for both the manager/customer as well as the programmer. In reviewing this once again, I think that many of these concepts go beyond this particular methodology and should apply to any kind of project (not even one that is related to software). For that reason, I have replaced the term "manager/customer" with "project stakeholder" and "programmer" with "project team member". Here are the rights.

Project Stakeholder Rights:

You have the right to an overall plan, to know what can be accomplished, when, and at what cost.
You have the right to get the most value out of every development week.
You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date.
You have the right to cancel the project at any time and be left with a useful working system reflecting investment to date.

Team Member Rights:

You have the right to know what is needed, with clear declarations of priority.
You have the right to produce quality work at all times.
You have the right to ask for and receive help from peers, superiors, and customers.
You have the right to make and update your own estimates.
You have the right to accept your responsibilities instead of having them assigned to you.

Wouldn't it be great if you were part of a project, either as a stakeholder or team member, that provided you these rights?

Make it happen, and establish these as part of your role definition that is discussed at the beginning of the project. As a project manager, make sure it is your job to ensure that whatever you accomplish on your project is true to these rights. As a project team member or project stakeholder, make sure that your rights are being upheld throughout the project.

50 Beliefs about Projects

Thu, 11 May 2006 20:01:18 GMT

Even if you don't agree with the entire list, you or somebody on your project team have thought of each of these things:

It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women.
Nothing is impossible for the person who doesn't have to do it.
You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
At the heart of every large project is a small project trying to get out.
The more desperate the situation the more optimistic the situatee.
A problem shared is a buck passed.
A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.
A user will tell you anything you ask, but nothing more.
Of several possible interpretations of a communication, the least convenient is the correct one.
What you don't know hurts you
There's never enough time to do it right first time but there's always enough time to go back and do it again.
The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.
I know that you believe that you understand what you think I said, but I am not sure you realise that what you heard is not what I meant.
What is not on paper has not been said.
A little risk management saves a lot of fan cleaning.
If you can keep your head while all about you are losing theirs, you haven't understood the plan.
If at first you don't succeed, remove all evidence you ever tried.
Feather and down are padding, changes and contingencies will be real events.
There are no good project managers - only lucky ones.
The more you plan the luckier you get.
A project is one small step for the project sponsor, one giant leap for the project manager.
Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.
If everything is going exactly to plan, something somewhere is going massively wrong.
Everyone asks for a strong project manger - when they get them they don't want them.
Overtime is a figment of the naïve project manager's imagination.
Quantitative project management is for predicting cost and schedule overruns well in advance.
The sooner you begin coding the later you finish.
Metrics are learned men's excuses.
For a project manager overruns are as certain as death and taxes.
Some project finish on time in spite of project management bestpractices.
Fast - cheap - good - you can have any two.
There is such a thing as an unrealistic timescale.
The project would not have been started if the truth had been told about the cost and timescale.
A two-year project will take three years, a three year project will never finish.
When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.
A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
Warning: dates in a calendar are closer than they appear to be.
Anything that can be changed will be changed until there is no time left to change anything.
There is no such thing as scope creep, only scope gallop.
A project gets a year late one day at a time.
If you're 6 months late on a milestone due next week but really believe you can make it, you're a project manager.
No project has ever finished on time, within budget, to requirement
Yours won't be the first to.
Activity is not achievement.
If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it.
If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!
The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
The sooner you get behind schedule, the more time you have to make it up.
The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.
Good control reveals problems early - which only means you'll have longer to worry about them.

Do not fall into the schedule trap!

Mon, 08 May 2006 16:16:12 GMT

As all project managers know (or should know), there are four constaints that must be managed on a project at any given time.

Cost - How are you going to do it? (People, equipment, and other financial resources needed to accomplish the project)
Schedule - When are you going to do it? (Arrangement of tasks to determine key milestone dates)
Scope - What are you going to do? (Deliverables and Tasks necessary to accomplish the goals of the project)
Quality - How do we know when we are done? (Criteria such as performance, stability, usability many defined by the end user)

You then determine how you will manage each of these by putting these into three categories:

Sacrifice this last – State which one (and only one) of these is the highest priorities and should not be compromised.
Retain these if at all possible – there may be exceptions, but try to maintain these priorities unless they conflict with the priorities in the group above.
Sacrifice these first – These priorities are more considerations than requirements, where possible try to keep these unless they conflict with any priority in the higher groups.

Management seems to prioritize based on promises made, so they would rank these as:

Schedule
Scope
Quality
Cost

However, what happens is that all of these become non-negotiable - "We must hit a date, with all of these functions, with the highest quality, and you have limited budget and resources." Therefore, the project manager has no choice but to spend as much time up front understanding the complete scope and quality requirements as well as determine (and hold on to) the resources they need to accomplish the tasks in as little time as possible. They also know that any changes in scope are going to push out the schedule so they do what they can to push off changes in order to please management's desire to hit the schedule dates.

The project team however, knows that it is impossible to understand fully everything you need to do on the project and despite their best attempt of estimates they fall short on on the realities. Knowing that the schedule dates are most important to management, and not wanting to let their fellow team members down, they do their best through heroics to get the additional work done on time. This is accomplished two ways, either in working additional hours or putting less time on quality. There are only so many more hours people can put into a project, therefore less time is put on quality or scope. Therefore, less time is spent on testing which raises the overall risk and possibility of not being accepted by the end user. Therefore, they end up ranking as:

Schedule
Cost
Scope
Quality

Does this sound familiar to you? If so, what do you do to avoid this schedule trap? Here are some ideas:

Don't forget about customer value. No matter what you do, you must make sure that you deliver something of VALUE to the end user. The customer won't care if you hit a date if what you deliver in incomplete or unstable in their eyes. They just want something that works and makes their lives better than before the project.
Deliver in smaller increments. Most projects are WAY too long. If you project is six months or longer, consider breaking it up into multiple projects. This will keep the scope smaller and easier to estimate and manage changes.
Develop in iterations. Instead of the traditional lifecycle of requirements, design, develop and test on the entire scope of the project -- try breaking the scope into sections, then applying the lifecycle to each of those pieces. Taking this approach wil better ensure that you deliver the most functionality in the least amount of time because you have less scope to work with.
Accept and not avoid changes. Changes are going to happen whether or not you like it. With every change comes an evaluation of how each change impacts cost, schedule, scope and quality. If you are doing the things above you will ensure that each change adds to customer value and can fit the schedule in the appropriate iteration and release.
Show the evolution of the project through schedule "snapshots". Team members and management can learn a lot from project managers about the reality of projects just by showing them how the project has evolved over time. Most of them have seen the baseline schedule that was established at the start of the project. However, many of them don't realize how the schedule changes over time. It would be best for the project manager to take "snapshots" of the schedule frequently on the project and show them to the team members and management. Educate all of them on how the changes occurred, both good reasons and bad.
Prioritize your scope. Though management will say that everything in the scope is a high priority (otherwise why would it be in the project), when pushed they will be willing to forgo having some features. Don't just prioritize at the beginning of the project, but as changes come up in the project. Always work on the highest priority items first so that if you must get things done by a particular date, you can ensure that the important things were done.
Clarify your quality. Make sure that the project team knows how to measure the success of the project (In other words, what is good enough?). What are your quality criteria i.e. performance, scalability, usability? What is the threshold measure for each of the criteria e.g. Each function must handle x customers at once time at take no longer than y time? What is the priority of each of the criteria?

A downside to collaboration?

Fri, 24 Mar 2006 17:10:04 GMT

How does your organization handle the appropriate amount of consensus to reach decisions?

What I love about my company is that they strive to get many perspectives from within the company on decisions that impact the development of our products - Sales, Marketing, Support, Developers, Quality Assurance, etc. These people are the particular experts in their areas, so they can shed light on something from their viewpoint that you may not see from your vantage point. People also feel empowered and a larger sense of ownership in what goes into our products. This is good, but there can be too much of a good thing....

The problem I see this causing is when you can get into what software engineering circles refer to "analysis paralysis". If you involve everybody in every decision, it becomes highly inefficient and you can take forever (usually in LONG meetings) trying to get everybody on the same page. If there are many people with various perspectives that clash, this can be a painful process. However, if you don't involved people, they feel disrespected and you could be losing a valuable perspective that could make your project a success. Eventually, the team has to come to a decision and this decision may not be agreeable to many of the participants. Sometimes, as the project manager you have to make tough decisions that may not be popular by many but need to happen regardless.

I face this kind of struggle in many of the decisions I need to be involved in as one of the key project stakeholders with every project. I don't want to hurt feelings, egos, etc...to the point that when I really need to hear from those people they choose not to participate. On the other hand, too many cooks can spoil the pot, and we must move on especially with minor decisions.

I am a firm believer that collaboration and communication is essential if you want to have a successful project. I also believe it is good if the team can agree on many of the decisions because they will be more motivated to make the project successful and they believe in the goals of the project.

So is my organization suffering from too much consensus, or is this just a challenge that comes with the many benefits of collaboration, communication, team building and consensus?

Team Members

Thu, 02 Mar 2006 20:59:20 GMT

We talked about team leaders, so what about team members? Here you go...

As a team member, I will:

Demonstrate a realistic understanding of my role and accountabilities. Skip: In order to demonstrate that, you need to work with your team leader to fully understand your role and responsibilities. Once you understand those (perhaps writing them down would be good?), you need to remind yourself as you proceed through your work. "Am I doing what is expected of me?" "Are there things that I should be doing?" "Are there things that I shouldn't?"
Demonstrate objective and fact-based judgments. Skip: Avoid making assumptions on your own, validate them with others on the team. You may be making assumptions or creating scenarios that would never happen. Instead, get your facts wherever possible.
Collaborate effectively with other team members. Skip: Constant communication and interaction with the team is critical for success. Don't go work off in a corner for long. We all need our times of privacy and focus, but check in with the team often to make sure everyone is on the same page.
Make the team goal a higher priority than any personal objective. Skip: For us, the team goal is doing what is important for our customers through solutions we provide. If there are things that would be nice but we can't justify for our customers, we won't (and shouldn't) do them. Political and personal agendas should be squashed as soon as they are evident. Don't get caught up in them yourself!
Demonstrate a willingness to devote whatever effort is necessary to achieve team success. Skip: It's all about the team! How do we achieve success? By focusing on our goals and helping each other out. For example, if you are ahead of schedule with your work and see a coworker struggling then help that person out. What's the use of getting ahead if ultimately we fail as a team?
Be willing to share information, perceptions and feedback appropriately. Skip: Some people treat knowledge as some kind of power. If I keep the knowledge, I'll be needed and feel important. If I give away the knowledge, I lose my standing. Baloney! Knowledge is only powerful if it is shared and useful to the team. Otherwise, you could hurt the team's success by keeping critical information.
Provide help to other team members when needed and appropriate. Skip: Provide easy access to your knowledge, experience, skills, etc. Sometimes as individuals we get too focused on our particular piece and stick our "heads in the sand". Look around occassionally, and see how the team is doing. If you can help, do so.
Demonstrate high standards of excellence. Skip: As a professional, be an example to others on the team. Raise the bar of quality, efficiency and effectiveness. If each person has that mentality, the team as a whole will be working at its peak!
Stand behind and support team decisions. Skip: Sometimes you will agree with a particular decision. Sometimes you won't. In those cases especially, once the decision has been made show your support. Nobody likes to have a team member who sulks at a decision that they didn't agree on, just to wait for the opportunity to say, "I told you so".
Demonstrate courage of conviction by directly confronting important issues. Skip: Don't ignore the pink elephants that are in the room. Confront the issues head on. Don't make them personal, and focus on solutions not how we created the issue. By having the entire team focused on "working the solution" you will avoid costly problems later on because of ignoring critical issues.
Demonstrate leadership in ways that contribute to the team's success. Skip: Even if you aren't in a Team Leader position, each person is a leader in their own way. When the team needs direction from you on something that is part of your role and responsible, lead the team at that point. Step up and represent your part of the project.
Respond constructively to feedback from others. Skip: Hopefully, feedback from others will be in the form on constructive criticism. Even if it isn't, the ol' adage "Turn the other cheek" is appropriate. If you feel the feedback is inaccurate, challenge it. But challenge it in a way that isn't personal, and both parties can learn from the experience. Again, focus on the issue and not the person and you should avoid any confrontations that aren't helpful for the team's success.

So how well do your project team members stack up? If not so good, you might want to introduce these guidelines

Team Leaders

Mon, 27 Feb 2006 16:48:39 GMT

I have this posted by my desk and look at it often as a reminder for how team leaders should behave. I have provided my comments after each one.

As a team leader, I will:

Avoid compromising the team's objective with political issues (Skip: We aren't a team if there are personal or hidden agendas. Assuming the team has clear goals are what is expected, we need to make sure that the team stays focused on those goals. Getting involved in political issues, most that you can't win or is out of your control anyways does nothing but waste time.)
Exhibit personal commitment to the team's goals (Skip: Once you have goals for the team, you need to get everybody on board. As a leader, they will be looking to you on your commitment. People on the team will see through you if you don't believe in the goals yourself. You can't get them on board if you aren't there yourself! If the goals aren't clear or your disagree, work with those that are forming the goals to get them to a place where you believe success will happen and you can commit to those goals. Most likely, you will then have an easy time getting others to commit.)
Not dilute the team's efforts with too many priorities (Skip: The more priorities you have, the harder it is to determine which order those priorities should be implemented. Also, the more dependencies and possible conflicts you could have with those priorities. Start out small and make sure that the team can commit to the priorities by implementing those with the level of quality that you expect. Then as the team accomplishes those priorities, have others "in the wings" that can be ready to give to the team. The less you have to manage, the more you can focus on the implementation of the work. After all, quality IS more important than quantity!)
Be fair and impartial toward all team members (Skip: Don't play favorites, and treat each people with the same respect and trust. We try to treat each team member as the "expert" in their particular area. They may not be an expert overall in their career, but for what is expected in their role on the team they are the expert. Therefore, treat them as such and you won't have any problems.)
Be willing to confront and resolve issues associated with inadequate performance by team members (Skip: In the previous bullet, I talked about each team members being an expert. Sometimes, even experts have struggles in their performance. Each of our teams meet on a regular basis just for 15 minutes. Why? So that the team leader can know how the team is working together on their goals and to determine where bottlenecks or obstacles could exists....and remove them. On a personal level, if a particular team members is showing inadequate performance it may or may not be their fault. They may be dealing with technology or tools that they aren't familiar with. If so, training or mentoring from other team members or the outside is needed. They may be waiting on other work from team members that has a dependency on their work. If so, perhaps they can help their other team members get the dependent work done first together.)
Be open to new ideas and information from team members (Skip: Never assume that you have all of the answers. Never underestimate the power of a team. Never assume that there are problems that are unresolvable. You will be surprised on what the team can accomplish if you give them the ability to contribute towards the project. More than just assign tasks, get them involved in the early brainstorming and allow time for feedback and research. Some of the best solutions and implementations I have seen from teams are those that weren't planned by the team leader or other management. They came from ideas from the team.)

If you are a team leader or know of one, does the list reflect the behavior?

Planning the unplanned work

Tue, 24 Jan 2006 20:32:34 GMT

Dwayne, my good blogging buddy over at Genuine Curiosity, must be reading my mind. His post called "Unplanned work - the silent killer" is a constant challenge for project managers everywhere. Why? Because it is hard to plan those things that are unpredictable, yet can cause problems in your projects if not considered. What are some of those things? Well, sick time, customer support, emergency issues, even things such as time spent on email, training and research can all fit into this category.

So, how have we handled this on projects? It has evolved over time in three phases, the last two phases we are current undergoing.

Phase 1: Create a generic buffer of working time each week that applies equally to every person. We set aside two hours a day for unplanned work. Therefore, if a person works a 40 hour week, they are truly starting at 30 hours a week minimum towards project (planned) work. It can go up from there if the person doesn't have as many unplanned hours or works overtime, but that isn't expected or planned that way.

Example of Phase 1: Suppose you have three project resources - Tom, Dick and Harry.

Tom - 6 hours for planned time, 2 hours for unplanned time (per day).

Dick - 6 hours for planned time, 2 hours for unplanned time (per day).

Harry - 6 hours for planned time, 2 hours for unplanned time (per day).

Problem with Phase 1: Not everybody needs the same allocation of unplanned work. Plus, for some they may use up the unplanned time whether or not they needed it because it was available. Therefore, we came up with Phase 2.

Phase 2: Create a buffer of working time each week that applies uniquely to each person. It is still based on an average amount of hours per day, but each person's average is different. This can be based on actual information over time. Therefore, the people who go "fight the fires" as Dwayne puts it will have a higher buffer than those that don't get as involved.

Example of Phase 2:

Tom - 7 hours of planned time, 1 hour for unplanned time (per day).

Dick - 6.5 hours of planned time, 1.5 hours for unplanned time (per day).

Harry - 6 hours for planned time, 2 hours for unplanned time (per day).

Problem with Phase 2: Though this is better, we still didn't have enough actual data gathered to see if the average was correct. Sure, there were days where we could easily see it was accurate, but other days we weren't sure. Therefore, the average may be off for some people. Therefore, we came up with Phase 3.

Phase 3: Start tracking unplanned work, and plan for some of it in your projects. Instead of a generic average of hours for each day and week, start using some better numbers based on actuals. This also helps show the direct impact of unplanned work on the project. You still can't plan things such as sick time and emergencies, but you can with things such as customer support. You can also try to schedule particular people to handle emergencies and other fires if they are critical at that time for project work.

Example of Phase 3:

For a two-week period (instead of an arbitrary hours per day):

Tom - 40 hours of planned time for project A, 20 hours of planned time for Support, 8 hours for vacation, 12 hours for unplanned.

Dick - 50 hours of planned time for project A, 16 hours for vacation, 4 hours for Training, 10 hours for unplanned.

Harry - 60 hours of planned time for project A, 8 hours for Research, 12 hours for unplanned.

Problem with Phase 3?: Time will tell. Using the agile idea of velocity, we are calculating this at an individual level, then rolling up the velocity to the team level to determine what the team can do in each iteration. With this approach, we can add tasks to each iteration that aren't related to the project, but impact the individuals. Therefore, we are creating bucket of actual time that can be used to "plan the unplanned work".

Chunking the work

Fri, 13 Jan 2006 16:39:56 GMT

No, I'm not talking about "take this job and shove it"! Instead, I want to discuss what I am learning with Agile that is changing the way I and others are thinking about approaching our work.

In traditional project management, you are first to define the scope of your project in determining what deliverables you will provide usually at the end of the project. The team then uses a Work Breakdown Structure (WBS) to determine how to go about the work. Though this helps each individual have a better understanding of what is needed and how to implement, it is still an "all or nothing" deal. Therefore, a lot of effort is put up front on defining everything you can for the deliverable, with the expectation that it all of the scope should be completed by the end of the project.

In agile, the thinking is much different. Instead of thinking of a project as a whole, you are thinking in terms of smaller increments of work called iterations. Typically, these iterations last 2 - 4 weeks each and are consistent in length throughout the project. It is up to the team to determine what can be completed in each of those iterations, and each deliverable must provide something that is working. This should not be confused with releasable, as releases could contain several iterations. This is where people need a different mindshift. They have to start thinking in "chunks of work". How should they do that? By asking themselves, "what is the simpliest thing the team can come up with in that period of time to begin to demonstrate the functionality being asked?" Their thinking has to be in terms of incremental and evoluntary. Their work with each iteration will build on their work from the past iteration, not necessarily be new functionality. They have to work with the customer to prioritize these "chunks" by the value the customer places on each piece, with the idea that lower priority pieces may be "sacrificed" if we need to delivery early or falling behind schedule.

How does this relate outside of agile? So many people think of their tasks in front of them as "all or nothing". Sometimes this can become overwhelming if the task is large or fuzzy. Therefore, it is those tasks that people put off until they have to, and therefore the overall productivity is much less. BUT, what if they thought about breaking their work into chunks? Then, they will at least get started on the work and start showing some visible progress along the way. If they focus on the most important pieces of their tasks, they may learn that "less is more" and find overall less work to do because they provided the most value first. Therefore, productivity soars, value is shown, morale is up and everybody is happy!

Next time you approach a project or even a series of tasks, think about "chunking the work" and see what results you get. You may surprise yourself on the results, and you will definitely get visibility by your co-workers and management.

Team Think vs. Individuals

Mon, 05 Dec 2005 22:24:10 GMT

A big paradigm shift for us moving to Agile Development is the idea that estimates and design of the solutions are done by the team instead of pass around from individual to individual. Before this shift, I knew of software development as this:

Customer provides business requirements.
Business Analyst creates functional requirements from business requirements through Use Cases or other methods.
Developers take both functional and business requirements and develops technical requirements through detailed design activities and create overall Specifications. Developers create estimates.
Developers implement Specifications. If there are changes, they are managed through Change Requests.
Quality Assurance (Testers) determine test requirements from Specifications and Change Requests. QA creates estimates.
Other people on the team (technical writers, marketing, sales, support technicians, training) begin to implement based on the specifications and Change Requests. They create estimates.
Developers complete their initial development and testing effort.
Quality Assurance and other people on the team implement their efforts based on what Developers have completed.
Releases get passed back and forth between the two groups until everybody feels the solution is ready for customers.
Update gets sent to customers with changes.

Now, I see agile development a much different way:

Customer provides business requirements through Features.
Customer provides business requirements through Features. Team provides a rough estimate of what the entire team will take to implement.
Business Analyst works with entire Development Team to create functional requirements from business requirements through Use Cases or other methods to create Story Cards.
Team takes each Story Card. Customer provides Acceptance Testing. Team estimates effort for each Story Card.
Story Cards are scheduled into Iterations. Releases are determined after several iterations.
At the start of the Iteration, Story Cards are further elaborated into Tasks and estimated.
Team commits to what is provided in the current iteration. Any change requests are considered in future iterations. Team must provide working software with each iteration. Working means free of any critical defects and must meet Acceptance Tests.
Team reviews with Customer the results at the end of the iteration.
Customer approves iteration.
At the time of release, update gets sent to all customers.

Though things start out and end on a similiar note, things quickly change with agile development. It is no longer a handoff between groups to do their part off of some documentation, leaving it to the document to tell what the solution needs to be. Instead, the team is together, having all of those conversations and determining as a team how they are going to implement each feature or story right at the time they are ready to implement. The communication is happening directly through collaboration, and not indirectly through emails and other documents.

Will a solution be better with the "team-think" approach instead of the "individual" approach? Time will tell, but I can tell you that the method of handoffs through documentation has its own problems. With the Agile approach, the solution will only be as good as the team. With the older approach, the solution can also only be as good as the documentation. Even if the team is good, the documentation can be shoddy and cause unnecessary frustration and rework due to misinterpretations of the documentation. This can happen with collaboration, but the inconsistencies should get caught by somebody on the team.

This picture is worth a thousand projects

Thu, 01 Dec 2005 20:02:48 GMT

Well, maybe I haven't done a thousand projects. But, for the ones that I have seen this looks very familiar!

via Scary Ideas

Agile-Adaptive Management

Thu, 27 Oct 2005 15:41:51 GMT

A few posts back, I talked about the Agile Manifesto, which focuses on the core principles of an agile team. Leaders from the Agile community decided that something more should be said for those that manage agile and adaptive teams. Thus, Agile Project Leadership Network (APLN) was born.

APLN was founded in 2004 by a group of people who are active in writing about, practicing, and evangelizing the movement towards fast, flexible, customer value driven approaches to leading projects of many types. Although this organization is separate from the Agile Alliance, our intention is to work closely with that group within the software community, but also work with people and companies outside of software and IT to help them become better Project Leaders.

This group was also responsible for their own manifesto, called the Declaration of Interdependence (DOI). A group of managers, authors, consultants, and team members from different project and product domains came together to discover common ground with respect to Agile and Adaptive Management (Similar to the Agile Manifesto meeting of 2001). This group represented people from the software development community (Alistair Cockburn, Mike Cohn, Jim Highsmith), the product development community (Preston Smith), and the general project management community (Doug DeCarlo, Robert Wysocki). Six core values emerged from that collaboration:

We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared ownership.
We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through situationally specific strategies, processes and practices.

From a executive management perspective, this is great material to sell upper management on the business advantages of moving to agile or adaptive development. They think in terms of management, and understand less about the inner workings of an agile team (either because they don't relate or don't desire that level of detail). This still speaks to the core values of agile, but in terms management likes to hear (I highlighted those terms above). If you are a manager or trying to sell management on agile, check out the APLN. They have some excellent resources.

Cross Functional Approaches

Fri, 21 Oct 2005 23:12:14 GMT

Pete Beherns, otherwise known as the Agile Executive, has a great post called "Is your organizational structured for success?".

Though his article focuses on Agile development, the heart and sole of the post is the discussion of five types of structures:

Functional – the project is divided into segments, which are assigned to relevant functional areas or groups.
Functional Matrix – A project manager with limited authority is designated to coordinate the project across different functional areas. The functional managers retain responsibility and authority for their specific segments of the project.
Balanced Matrix – A project manager is assigned to oversee the project and shares the responsibility and authority for completing the project with the functional managers; there is joint approval and direction.
Project Matrix – A project manager is assigned to oversee the project and has primary responsibility and authority for the project. Functional managers assign personnel as needed and provide technical expertise.
Project Team – A project manager is put in charge of a project team composed of a core group of personnel from several functional areas. The functional managers have no formal involvement.

I will say that over the life of my career, I have experienced (and experimented) with all of these types of structures. Currently, as a functional manager, I try to provide some guidance to the PM on personnel and technical expertise, but otherwise the project manager is responsible for the success of the project and directing the project team. So, we would fit a "Balanced Matrix".

That seems to work for our organization, as our functional managers are still responsible for the development of the people that are working on projects. Therefore, their involvement in necessary to some degree. As long as the project team can achieve the project goals of cost, schedule, scope and quality that was agreed upon by the business stakeholders (which happens to be the same group as the functional managers) the project manager has full authority. Otherwise, the issues will get escalated to the business stakeholders to get resolved with the project manager.

As we move towards agile, the cost and schedule will be fixed within iterations. However, the scope and quality could change often to determine what is good enough right now to bring customer value. This may require too much time of the functional managers going forward, which could move us to either a "Project Matrix" or "Project Team" environment.

Who is doing your estimates?

Wed, 12 Oct 2005 21:41:12 GMT

I went to an interesting workshop on Monday. Mike Cohn of Mountain Goat Software was the speaker and the topic was on Agile Estimating and Planning. For those not familiar with agile development, Mike is one of the founders of the Agile Alliance as well as the Scrum methodology. He also was involved in the development of User Stories and Story Points.

There were a lot of good takeaways from this session, but one thing in particular struck a cord with me. As we were discussing techniques on how to estimate user stories (you can also think of them as high-level feature requirements), Mike was showing us ways through exercises to do the estimates as a team.

I had been taught that it was the individual that is assigned to tasks that does the estimates, and not the team that determines it together. I had learned that is was good for the team to get together to discuss some of the requirements and general scope of the project. However, when it came down to estimates, that usually involved the individuals going off for awhile and coming back with an estimate. When we received that estimate, unless it was extremely outragious, we usually accepted it as is and moved on.

An interesting thing happened in our exercises, as the team worked on estimates together. We were figuring out not just the requirement but getting at least a rough idea on the solutions while making a LOT of assumptions together. And, then it struck me.....I wonder what goes through an individual's mind when providing estimates. What is their context? What are their assumptions? What solution do they see in the head? If as a team, we were finding out that our assumptions and solutions of the requirements were much different, wouldn't the same happen with each individual.

Since the requirements are high-level, there is a lot of "filling in the blanks". You can usually accomplish that by getting more into the details through detailed design and implementation. Otherwise, you make a LOT of assumption. If nobody is clarifying those assumptions when an estimate comes in, how accurate is that estimate? If in my mind the solution is easy and small, but another person's mind is complex and risky...wouldn't we come up with different estimates?

Going forward, I think I'm going to always recommend that the team develop the initial rough estimates for the project. Then, as we get into the tasks, the individuals can refine those estimates based on their comfort level. At least by that time, you are ensured that they are on the same page with their assumptions!

View from the ground floor

Thu, 06 Oct 2005 22:53:15 GMT

There are many good blogs out there on the topic of Project Management. However, most of these authors of these blogs have been managing projects for many years. How about hearing from somebody that is just starting out?

That's the premise for a new blog that I am happy to introduce - Rookie PM. Casie Hulden is the author of this blog, and she is fairly new to project management. She will be sharing with other project managers that are just starting out her experiences. I am sure that she would also like to get feedback from those vetrans out there of lessons that they have learned and would be willing to share with all project managers.

Please take a look and let her know what you think! Also, spread to the word to others who want to learn more about project management from the "rookie" perspective.

Oh...and did I happen to mention that I'm Casie's manager? Makes me so proud!

A Project's Ultimate Goal

Mon, 03 Oct 2005 18:24:28 GMT

I cringe when I hear a story published that the project manager was proud that he or she was able to get a long term project on time and within budget. But, what does that mean exactly?

Did the end solution meet all of the specifications determined up front?

Did the project team consist of the same people that worked reasonable hours on the project?

Did the project have no risks that occured or did those risks not impact the scope, cost and schedule?

Did the schedule accounts for all tasks and issues that weren't planned up front in the project?

Did the project not allow for scope change or involvement from the customer?

I would guess that the answer to all of these questions would be "NO". Therefore, cost, schedule and scope all did change from the beginning of the project until it's end. Therefore, why is there such a big deal to make sure that the project hits the date and costs? If these changes are happening, then the end user should be a part of those changes, and should see that things are changing all of the time. With that said, isn't hitting a schedule and budget on target just coincidence? That for some reason, all of the stars aligned just right and you happen to meet those goals.

Then, you can publish and brag about how successful your project was for the right reasons!

No News is Good News: Good or Bad Practice?

Mon, 26 Sep 2005 18:34:47 GMT

"No news is good news". This phrase is spoken throughout organizations across the world. It is said by managers and non-managers alike for the following reasons:

You are a project manager and expect that the team is empowered to make good decisions. Therefore, any news that gets escalated to them is usually bad news that they must help with.
You are on a project team and anticipate some issues that the team must deal with, however nothing has been communicated. Instead of checking into it, you are hopeful (ok, perhaps wishful) that everything must be ok.
You are a project stakeholder and haven't heard from anybody on the project team for some time. You haven't heard of any problems or delays so you assume that the team must be doing alright and will deliver on time, within budget and meet expectations on the deliverables.
As a member of the project team, you don't want to look bad in front of the others. You know that you aren't going to meet your deadlines, but don't want others to know. You adhere to the "don't ask, don't tell" policy - your project manager hasn't asked if things are going wrong (assuming that no news is good news) so you won't tell him or her otherwise. Through heroics, you will work extra hours and do "whatever it takes" to get it done even though it is a long shot.
As a functional manager, your recent new hire has had little experience with the technology the project team is developing with nor the processes that they are doing their work. This person has had some training and initial orientation through HR, but is now on their first project. You haven't interacted with this person very much, but assume that they must be busy and productive since they haven't asked for either your help or help from co-workers.

All of these have something in common - the lack of good communication, follow-through and accountability.

Who is an expert?

Mon, 19 Sep 2005 19:50:04 GMT

Lisa asked an interesting question in her latest post over at Management Craft called "What is expertise?". She goes on to ask:

"When are we regarded as experts? I know this is an unanswerable question because it is largely in the eye of the beholder, but I wonder about the common notions of expertise."

In our work culture, especially in how we do software projects, we talk about handling things at the lowest level of management. Why? Because we consider each person dedicated on the project to be the expert in his or her area. Does this mean that each person has to come with many years of work experience, various degrees, books that they have published, in order to be an expert? I don't know about your work situation but we couldn't afford having these kinds of experts employed. Yet, each person on our team is in expert. How can that be? Well, the definition of expert is a simple one, but perhaps different than others might see it...

Our definition of expertise is "The person in the room responsible for the success of the project from their perspective using their unique skills, talents and knowledge." Another way to look at it is "The smartest person on the team given their particular role and tasks on the project".

Given this definition, each person on the team brings a certain level of expertise to the group. By labeling these people "experts", it also brings on a certain level of appreciation, trust and respect from the team on each person's contribution. This makes communication, collaboration and teamwork much more effective since the team needs to have everybody doing their part for the team to be successful.