In its simplest form, Implementation is generally considered by team members as when the project starts. In a phase-controlled project, project team members are only minimally involved prior to the implementation phase. At this point, the scope should be approved and the project is starting in earnest. Implementation is very often the longest phase in the project lifecycle.

From a software perspective the traditionally agreed upon sub-phases include requirements, design, develop/build, and test. These can be extrapolated in many different ways and approached using different methodologies such as Agile, XP or countless others. But, at the core of the project you are managing these four things:

Understanding in a documented way what the end customer needs/wants (Requirements)

Extrapolating the understanding of the requirements into a technical specification to prove that the wants and needs of the customer can be addressed (Design)

Making the requirements a reality (Development/Build)

Test the results for accuracy/completion (Quality Assurance or Testing)

A picture is worth a thousand words so I thought I would start with a diagram. I recently had the need to explain an overview of the Project Lifecycle within the context of software development so I thought it would be worth sharing here. This diagram is by no means original or even possibly unique. The initiating, planning, executing (implementation), monitor and control and closing match the PMBOK definition for project process and the sub-processes are generally agreed upon across the industry, but everyone enjoys a good picture and so here is mine for explaining how things work.

In addition to checking for solid requirements using the SMART methodology it is important to properly prioritize or categorize the project requirements. This can become especially critical in the large project or project with seemingly unrealistic expectations. There are many ways to categorize these; personally I like to apply the easily understood labels of must-have and nice-to-have.

In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.

Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer. Many people believe this is the way projects should progress or at the very least consider it a natural course for projects to take. This is not the case. Starting with adequate and thoughtful requirements can eliminate, or at the very least, significantly reduce, the amount of issues and re-work that are required in a project. So let’s start with the basics of requirements. Read the rest of this entry »

My goal with the project example is to create a scenario that is similar to those faced in real projects. I find, too often, that textbook examples overly simplify scenarios to the point that the answer is so obvious that when faced with a real world example the less experienced project manager cannot distill the issue.

Mark is a project manager for Custom BoatBuilders, Inc. Bill manages the custom building of boats for private consumers. Consumers contract with Custom BoatBuilders (CBB) to build custom watercraft for personal use. Mark reports to Steven who is the Client Relationship Manager. Steven’s responsibility is to work directly with the customer and secure a contract for the building of a custom boat. After a new customer contract is signed, Steven involves Bill to execute on the project. Read the rest of this entry »

Ah, the triple constraint, the cornerstone of project management and project management (PM) lingo. Along the way, I will try to cover the most common acronyms and lingo that are used in the discipline. I neither intend to promote nor condone any particular use, or in many cases, overuse, of project management lingo. My goal is to create familiarity with the terms as they are commonly used in practice.

The triple constraint refers to the three inputs that govern the ability to deliver a project. The three commonly agreed upon constraints are budget, time, and scope. They are often drawn in a triangular shape to represent the relationship between them. This triangular arrangement helps to represent that any adjustment to one of these factors will have an impact on the other two. This relationship will become clearer with examples. Let’s start with definitions: Read the rest of this entry »

After thirteen years of project management experience, mostly in software engineering, I figured I had something to share. I have a lot of passion around the triple constraint (if you’re not sure what that is, read on) and I love to teach. I’m currently a project manager in the corporate environment and would rather be teaching, so I though I would start this blog to share my experience with those that are interested.

My goal is to post a series of topics that relate to project management and more specifically effective project and requirements management. This is not meant to mirror a textbook and is written in an extemporaneous fashion. I hope to get a few readers along the way and am very interested in requests for topics as well as questions readers may have as a result of topics posted or issues they are facing in their own projects or project disasters, whichever the case may be.