Major Projects - Inequities Necessary?

The thought that "no correctly-spec'ed project gets approved" leads me to lots of questions, and no real answers this morning.

I was thinking about the massive projects that the world has seen, like the Pyramids, great Dams, Bridges, Skyscrapers and Railways, or well-designed and -architected cities in general, and wondering: Are these things we marvel at, built on great inequities? Inequities that people of certain demographics cannot even imagine (thinking about myself as a white, male, middle-class American).

It's not comfortable to think about, but would such marvels even exist if there were not the exploited and the exploiters? Can this said to have been even necessary for technical progress?

Food for thought.

Velociteach PM Poster - Observations

Velociteach created this excellent Project Management-related poster, talking about the gap between what users say they want, what they really want, what's sold, what's delivered, what's paid for, and what's supported. Are things really this bad? From experience on many a large project I would say they are.

Some Current Problems in Projects Today

This poster hammers home the concept that stated requirements have to be well-linked to what's delivered, a concept that has been emphasized for quite some time in software development camps as a reaction to "waterfall" type project management. If you're not familiar, waterfall is a "command-and-control" concept of PM where everyone marches lock step through phases, changing phases when the documents are signed off. That might sound comfortable to people who are not detail-oriented enough to really understand what is going on, but the reality is always messier. Other approaches such as or stemming from "Agile" or "Lean" software development, help keep the focus on what's valuable to the customer, and avoid meaningless rounds of documentation and signoff. Note, I did not say those approaches advocate not documenting at all, because that does not appear to be the case.

I was the Japan-based PM for an ERP implementation, where the head of the PMO at my client generally encouraged the use of more Agile methods. We never talked about Agile and what it meant per se, but recently studying Agile for how it might help me manage non-software development projects or general projects, I can see similarities between what's in the Agile Manifesto and Agile Principles, to what we actually did on the project.

One thing that we did which was rather too "waterfall" however, was an attempt to document all the user requirements up front, in a huge list. This quickly got unmanageable partly because we were trying to do requirements this way, with users inexperienced in ERP implementations, and partly because we were using email as a collaboration tool, which was a mistake as well. Thinking about that, users would have had a terrible time trying to remember what they said, in requirements meetings many months back, in specification review sessions. Adding to that the need for translation and interpretation services, it's a wonder we went live as successfully as we did. An attestation to having the same developers and coordinators involved the whole way through, and just general tenacity, if you ask me.

What to Do About It

In summary, my current feeling about what to do is the following:

• Though Email has obvious benefits and applications, attempting to collaborate in Email is not the right approach or, dare I say, any project. Instead, use a system like TargetProcess, LiquidPlanner, Unfuddle, MyIntervals or even BaseCamp.
• Use a V-shaped project process, to link user requirements to user acceptance tests, designs to design validations and so on, so that there is a check and balance in your process. Make it easy for users to see the link between what they asked for, and what was done in the end.
• Poorly-done Agile is just as ineffective as Waterfall, so if you are going to implement different methods, make sure they fit and that you do it skillfully so the whole entity supports it. Don't use Agile as an excuse to be lazy. In fact, Agile requires even more discipline in the team.

The jury is still out for me what the "best" method is and what the best collaboration software is, but I have taken my time to understand methods besides waterfall, and am beginning to apply them in practice. I will post here about my experiences from time to time. I hope you Enjoy this.

PM Process - Make sure it's done right.

In any project, there are varying levels of these broad-stroke activities, including Initiation, Controlled Implementation, Closure and Maintenance. I have arrived at this definition which we use at my company eSolia, by combining the PMI and Critical Chain methods, and massaging them based on a lot of experiences during projects over the last 14 years. One of the most important points is to do all the activities - don't skimp or flinch.

Initiation: The objective of the Initiation process is to assemble an organization's ideas and intentions to solve a certain problem, and organize them into a formal, planned, resourced and funded project. Initiation involves defining project terms of reference such as organization, objectives and scope, creating a workable and realistic schedule for the overall project and each stage, and establishing a business case to get commitment from project sponsors. A successful Initiation will ensure the project is set up to be successful, and increase the probability that high-quality product is delivered on-time and within budget.

1. Agree - rough project definition, agreement and contracting for Initiation.
2. Kickoff Project - arrange sponsor, high-level definition, team brief and kickoff.
3. Define - detailed requirements, objectives, scope, deliverables, solution outline, business case outline, training requirements, organization, administrative methods for change and QC, success criteria.
4. Planning / Scheduling - create project network from deliverables, identifying dependencies and special needs, task resource requirements and constraints, hand-offs, initial schedule, completion criteria, and task and iteration variabilities. With network, create realistic time schedule, with buffers, links and clearly identified critical path.
5. Close - update all documentation, update business case, present, assess stage, review next steps.

Controlled Implementation: The objective of the Controlled Implementation process is to manage work being performed during a stage, and to prepare for the next stage. Controlled Implementation involves synchronizing introduction of work, and then controlling and managing progress, quality, change, integration, issue management, reporting, team commitment, client expectations and provision of information for decision-making. When the process is successful, it can be expected that the stage can reach a successful conclusion and the project will progress to the next stage.

1. Kickoff Phase - review of phase details, kickoff.
2. Synchronize - Introduction of work carefully considering resource constraints.
3. Execute - perform tasks, controlling project buffers and handling project administration.
4. Close Phase - reporting and preparation for next phase.

Closure: The objective of Closure is to formally close the project. Closure involves tying down any loose ends, evaluating the final products of the project, establishing product improvement mechanisms, reviewing estimation and project process, and formally presenting and closing the project with signoff. A successful close ensures project value is communicated and understood, and allows project resources to be re-deployed.

1. Task Completion - complete any loose ends.
2. Evaluation - perform a post-mortem on project, evaluating performance and products.
3. Process Improvement - check process and make improvements as needed.
4. Project Close - formal document presentation and signoff.

Maintenance: Once a project is Closed, the maintenance of the situation or products which were implemented can be defined, planned and performed. Skillful maintenance ensures the benefits of the project are enjoyed in an ongoing manner.

1. Define - define maintenance objectives, budget, scope.
2. Plan - plan and schedule.
3. Execute - perform maintenance.
4. Review - periodic review.