Herding Cats

Attributes of Successful Projects

The NAVAIR Earned Value Management Tool Kit - available at the Defense Acquisition University web site. (When you reach this site, answer yes to the missing certificate)This site by the way has a wealth of resources for everything related to program management. If you're looking for something, start there.

Here's NAVAIR's restatement of the obvious.

NAVAIR EVM Guidance For Success And Failure Of Projects
Successful Projects	Failing Projects
▪  Effective project planning	▪  Inadequate project planning
▪  Effective project cost estimating	▪  Inadequate Effective project cost estimating
▪  Effective project measurements	▪  Inadequate Effective project measurements
▪  Effective project milestone tracking	▪  Inadequate Effective project milestone tracking
▪  Effective project quality control	▪  Inadequate Effective project quality control
▪  Effective project change management	▪  Ineffective project change management
▪  Effective development processes	▪  Ineffective development processes
▪  Effective communications	▪  Ineffective communications
▪  Capable project managers	▪  Inexperienced project managers
▪  Capable technical personnel	▪  Inexperienced technical personnel
▪  Significant use of specialists	▪  Generalists rather than specialists
▪  Substantial volume of reusable material	▪  Little or no reuse of technical material

Like all restatement of the obvious, many things are not so obvious.But notice the emphasis on Planning, Cost Estimating, Performance Measures, Quality, and Change Management. All activities that cause project churn. Even in the best of agile development, if the goal of the project keeps changing, and the agile team rapidly responds to these changes, money is being burned for work that may or may not be recoverable.

This is a fundamental "hidden cost" of poorly defined agile projects in the same way it is for poorly defined traditional projects.

If I create work product that is then tossed, it is a non-recoverable sunk cost

So ask these questions for your project, no matter the method used. And ask anyone who brings you a technology solution to your project - How does you new technology improve the probability of success?

If you notice in the NAVAIR table, people and processes dominate the conversation. Tools are a distant third.

Technical and Scientific Resources

There are many resources on the web for technical and scientific papers. Some are good some are politically motivated, some are just lame.

Here's my trusted list:

• Scirus - is a source of scientific information. But it also has many engineering resources and many project management topics as well
• Directory of Open Access Journals
• PEW Global Climate Center -with as much noise around this topic flying across the web, a trusted source of information is needed. Start here.
• Scribd - is a repository of articles and sometimes books on a variety of topics

Managing By Exception

PM Hut has a post on Managing By Exception. While the concepts posted there are good in "principle," in "practice" more needs to be in place to keep the project on track.

First there needs to be a set of clearly defined assessments of physical percent complete. Along with that some means of assessing the increasing maturity of the products or services produced by the project. And of course some type of "exit criteria" for each Unit of Work produced by the efforts of the project team. Finally, a means of identifying, handling, and reporting the risks to the progress of the project.

In the absence of this information, there is no raw material available to assess the exceptions. Only when the Plan, Schedule, Risks, and Measurement processes are in place, can the exceptions be determined. Having the Project Manager track and reviews but does not intervene only works if the "control boundaries" are defined in units of measure meaningful to the stakeholders.

As well the statement that "Management By Exception" is a relatively new concept is likely not correct, unless "new" means defined in the last 100 years. MBE is the basis of military command and control for small unit engagement. It was applied in the aerospace business in the late 70's.

Lazy Project Management?

PM Hut has a post about "lazy management." The idea that the PM reads the morning paper, chats at the coffee machine and generally "hangs around" watching people work is likely VERY domain and context sensitive.

I would be dumb struck to see the project manager for the recent I-25 rebuild by Kiewet Construction. Or the project manager for Building 777 at Rocky Flats, or the project manager for a $170M ERP integration at a health insurance company. Or the best example of the Program Manager for the major manned space flight program.

On those programs, the PM is not "running around with her hair on fire," but it is unlikely there is a spare minute in the day. As well the alternative is not to micromanage the work of others. Instead all project participates "execute the plan," in a manner appropriate for the scope and critically of the project. The more critical the project, flying to the moon, the more likely everyone is running at 110%.

If the project is a casual endeavor, then "lazy management," may be the norm. The notion of "managing" the project at the people level by the direct contact is also unlikely in critical projects. The work management is done through "work packages," with defined deliverables, measures of performance, and risk adjusted costs and schedule.

So where is "lazy project management" appropriate? Good question?

Lazy Project Management?

PM Hut has a post about "lazy management." The idea that the PM reads the morning paper, chats at the coffee machine and generally "hangs around" watching people work is likely VERY domain and context sensitive. 

I would be dumb struck to see the project manager for the recent I-25 rebuild by KiewetConstruction. Or the project manager for Building 777 at Rocky Flats, or the project manager for a $170M ERP integration at a health insurance company. Or the best example of the Program Manager for the major manned space flight program.

On those programs, the PM is not "running around with her hair on fire," but it is unlikely there is a spare minute in the day. As well the alternative is not to micromanage the work of others.

Instead all project participates "execute the plan," in a manner appropriate for the scope and critically of the project. The more critical the project, flying to the moon, the more likely everyone is running at 110%. If the project is a casual endeavor, then "lazy management," may be the norm.

The notion of "managing" the project at the people level by the direct contact is also unlikely in critical projects. The work management is done through "work packages," with defined deliverables, measures of performance, and risk adjusted costs and schedule.

So where is "lazy project management" appropriate? Good question?

My Six Honest Serving Men ...

Josh Nankivel is interviewed by a student from Help University College in Malaysia. One of Josh's statements rang a bell for me.

When asked, 

"What is the greatest challenge for you as a Project Manager?"

Josh said,

"The specifics depend on individual projects and their environment. In general, the greatest challenge is ensuring clarity of “what, when, who, why, and how” for everyone, including the customer, project sponsor, team members, and all external and internal stakeholders. Most project failures in my experience stem from a failure to do this."

This list of "questions" is from the Kipling Poem, The Elephants Child.

The answers to these questions must come from processes executed during the project. Here's my take on what those processes must be, taken from our process handbook.

There are 5 process areas used to answer the questions. 

Identify Needed Capabilities

Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. The ConOps (Concept of Operations) is a description of how the resulting product, system, or service will be used from the Point of View of the "customer." 

Establish the Requiremnets Baseline

Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology.

Establish the Performance Measurement Baseline

Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan.

Execute the Performance Measurement Baseline

Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.

Perform Continuous Risk Management

Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planningsm process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

At the highest level, these are the immutable processes needed to answer the Six Questions. This is a list of the "one true method" for managing projects, in the same way the Six Honest Serving Men, were Kipling's "one true method" for gathering the news while employed as a reporter in India.

There is more to managing projects than this of course. Along with the 9 Knowledge Areas and 6 Process Groups of PMBOK, any proposed project management method must address in some way, these items. In the same way as being a reporter is more than asking and answering Kipling's question.

In the end if you are not guided by these questions, the results will be disappointing to everyone, you, the customer, the stakeholders, and most importantly your ability to grow as a project manager.

20 Reasons Managers Fail and Ways to Fix Them

The Wisdom Journal posted a nice article on the 20 Reasons Managers' Fail. The response to these failures have themselves failed in a common manner. It goes like this. State the failure mode. Use the phrase "don't do what you see in the failure mode." This is the same as "doctor, doctor it hurts." "Then don't do that."

From my point of view in Program Planning and Controls here's some suggestions using the mechanisms of PP&C to solve the problem – well most of the 20 failure modes.

Failure Mode	Solution Using PP&C
Avoiding responsibility when things go wrong by blaming others	Build a responsibility assignment matrix for every deliverable in the project. Use this RAM to also define all the project management process accountabilities. This leaves not work uncovered. Everyone can see in this big visible chart of who is accountable for what outcomes on the project.
Failing to develop and maintain a high level of morale among employees	Well this is harder and comes back to a leadership issue. Not direct solution here.
Incorrectly identifying solutions to problems	Using the Integrated Master Plan, define the Significant Accomplishment and most critically their Accomplishment Criteria. These criteria define beneficial outcomes of the project.
Unable to effectively deal with people. Shows up as being too blunt, showing favoritism, or being harshly critical. May manifest by making comparisons to other stores, departments, or people	This is a problem of leadership and isn't going to get solved by a process. Get better managers and staff
Unable to effectively plan and organize. Shows up as getting bogged down with details so that overall planning or organizing isn't done	Get a Plan, a real Plan. One that shows how the products and services increase in maturity as the work packages of the plan is executed.
Inflexibility. Will not listen to others. Is completely self-centered	Leadership again
Failing to encourage subordinates to contribute ideas and suggestions	Leadership again
Neglecting to develop a team effort	Use the responsibility assignment matrix to publically show how all the participants in the project make their individual and collective contributions. You can see directly who is overloaded, who is lightly loaded, where the power is concentrated. Balanced the power
Has a quick temper, is thin-skinned, easily upset, temperamental, or overly sensitive to criticism – real or imagined	Dump this guy like a hot potato
Failing to think in terms of the entire organizational situation. Doesn't see the bigger picture. Shows up as being unwilling to cooperate with other departments or managers. Thinks his or her department is the most important to the organization	Build a Work Breakdown Structure (WBS) Build an Organizational Breakdown Structure (OBS) Use these and the Statement of Work (SOW) to assure everyone and everything is covered
Failing to develop subordinates	Leadership again Use the RAM to designate subordinates
Having a lack of self confidence	Get better people
Lacking ability to express ideas either orally or in writing. Is unable to give clear and concise instructions to employees	Project management is a full contact sport Look for another job The evidence that communication is taking place starts with the physical elements of project management. A Plan, the WBS, OBS, and other artifacts that are built collectively by the project team in public meetings
Lacking follow-through. Doesn't check to see that instructions are complied with, that performance standards are met and that objectives are reached	Plan of the Week is the first step Maybe Plan of the Day for those with short attention spans No tolerance of missed deadlines – period. The project is lost a day at a time
Resisting change and is unwilling or afraid to try new ideas. Shows up as a resistance to training opportunities for the staff or for the manager	Leadership problem Get new members. Don't tolerate this – period
Is a poor decision maker. Procrastinates in making decisions or jumps to conclusions. Takes action without thinking through all possible reactions. May use emotions to make decisions	All decisions are public events. How the decision maker accountable. Poor decisions over time, means getting a new decision maker.
Is unable to follow instructions. Fails to listen or ask questions when needed to clarify a situation	"look for work elsewhere"
Is disloyal to the organization, its employees, superiors, ideals. Shows or expresses contempt for policies, superiors, or departments	"Look for work elsewhere"
Lacking motivation. Is not a self starter. Has to be told what to do, when to do it, and how to get it done	"Look for work elsewhere"
Dislikes added responsibilities. Fails to prepare for larger responsibilities and growth	You're not PM, "look for work elsewhere"

Now this is not the end all of solutions, but ignoring the bad leadership for the moment, the mechanics of addressing the other issues is staright forward.

One of the real problems in the softer side of project management, is we put up with bad behavior way too long. The answer is the doctor answer.

Doctor, doctor we have bad leaders, bad behavior. Then either get a new job or get a new leader. Don't not tolerate this. If you do, it's just an excuse and you get what you deserve – a failed project.

Anything That Is General Is Not Helpful

Sitting on the M/W/F morning proposal management call, with 30 or so participants, there was a comment made by one of the prime contractor proposal manager...

Anything that is general is not that useful

This triggered several thoughts:

1. When there is a generalized suggestion regarding project management with no actionable outcome - it's just that a generalized suggestion.
2. When there is a generalized suggestion to replace one process with another - it's just that a generalized suggestion.

The business of writing proposals - especially for US Defense Department customers starts with a structured method.

1. Each statement must have an unassailable beneficial outcome to the buyer
2. Each description of an activity should provide:

● Statement of the action
● Outcome from that action
● Benefit from the outcome of the action

If the conversations around project management, agile development, and many of the other topic of PM were to follow this paradigm, we'd get a lot more actionable information coming our way.

Managing in the Presence of Change

Managing in the presence of change is a core competency of any project manager. The complete myth that traditional project management - read PMBOK - tries to control change, to prevent change, or to avoid change all together is nonsense. No credible project manager or project management processes tries to prevent change.
    The challenge though is to manage in the presence of change. First let's look at a quote from a thought leader in the requirements business:

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are -- Karl Wiegers

Now with this stating point how can we manage in the presence of change?

• Establish a baseline for the project as we know it now? What have we committed to do? Without this knowledge, we can't determine the impact of change.
• Capture change requests through some formal method. In other words, no private change requests. It would fantasy to think a change would not impact cost, schedule, or some behavior of the product or service. So assessing the impact of the change is the first step of managing in the presence of change.
• With the change requests in hand, assess the impact on cost, schedule, and product behavior. Why are we doing this change? Does this change disrupt previous work, so we have rework? Does this change impact future work, so we have to replan? If we don't know the consequence of the requested change, then we can't make a decision about what to do next.
• Assess the change in the context of the larger picture. Will this change make the system less reliable? Less robust? Less attractive to the users? Less anything that we don't want to happen? But most of all will this change disrupt the architectural integrity of the system. This is a critical success factor for every type of system - software, hardware, operational. This integrity is the core attribute for making the system sustainable over it's life.

Now that we have a simple process for managing in presence of change. Next we need a process to deliver these activities:

• The Change Control Board is a simple process. This can be formal or it can be very informal. Formal means forms, meetings, signatures. Informal means face to face agreement of what to do next.
• Capture the approved decision in some way. Make sure everyone impacted by the change knows they are impacted by the change. Have them tell you they know they are impacted by the change.

This is the simplified approach to managing in the presence of change.

Collective Responsibility is No Responsibility

It dawned on me today the primary difference between agile management and actual management.

Collective Responsibility is No Responsibility

On our programs there is a single point of integrative responsibility - The Program Manager. The Program Manager is accountable for getting the program done. For getting the product delivered to the customer. For leading the team to the launch party.
    Of course there are many contributors to the success of the program. But there is only ONE contributor to the failure of the program - The Program Manager. Everyone knows this. Everyone accepts this. Every lives by this rule. Everyone supports the Program Manager. If they don't, they can look for another program to work.
    Why is it we get this confused in the agile IT world. Is there a different work ethic? A different egalitarian motivation is let people "try there hand," to learn by failing. Maybe.
    On the other side how do people "learn" in our world, if they don't fail?

Here's My Tale of How That Happens
    I was a young programmer. OK, not that young, having server a tour in Vietnam between undergrad and grad school. A fresh developer with a graduate degree in physics, who knew how to write a micro-coded version of partial differential equation solvers for digital signal progress algorithms. Finite Impulse Response Filters and Kalman Filters. Things found in particle accelerators - my dream job. But also found in radar signal processors. These filters grab signals from way below the noise and turn them into "targets" that the anti-missile systems to which they were connected shot at.
    Our job was to replace an analog system with a digital system. A simple job. Write a FORTRAN program and some assembly language I/O drivers that is an exact emulation of an analog computer and a bunch of analog filtering parts. This is the easy part. The hard part is to make this program performance the EXACT same function, with the EXACT same response times as the analog computer. No analog computers had been around a long. Our boss had designed and built most of the analog computers on this system and was now a "big wig" manager. We of course being fresh young student thought his bald head was an indication that his had missed the technology revolution of embedded microprocessor based digital signal processing. The AMD 2910 bit slice machine was going to make look really old when our cleaver machine made his analog box go away.
    Trouble with analog systems is their algorithms are embedded in the arrange of circuits. The math description of the system is written in a manual - a document of the process. You documentation of what the system did. And the other problem with analog systems is there cycle time is limited by the speed of light. Plus a bit if delay for the response time to signal level changes. A hell of a lot fast than a 2901 bit slice machine emulating the linear amplifiers, slope inverters, op amps, integrators, differentiators and the other parts that implemented the sets of partial differential equations used to point the radar and process the signals into targets.
    Well after several months of coding and testing we were ready to show off our work. Our boss stood in the corner of a very large warehouse sized room, with the radar antenna in the middle mounted on a hydraulic steering pedestal, maybe two stories high. When we turned on our "digital emulation" of the analog control system, the antenna spun around looking for the signal source and slamed into the spring stops, shaking the build, our teeth, or our bosses hat.
    He leaned against the wall, recovered is engloish dirving hat that he wore everywhere to cover his cue ball head, and simply asked:

You boys know what the hell you're doing?

    Why am I telling this story? Because he was responsible and accountable for the success of our little Internal Research and Development (IRAD) project. No sharred, collective, communal responsbilty. Just Fred (Fred Leary). And is question has never left me. We had on one answer - "I guess not."
    When people talk about collective responsbility of development teams I get an internal smile.
Oh you need to talk to Fred about that, I think to my self.
I'm he's long passed away. Our analog systems engineer, who designed and built F-86D flight controls.
    So when some says "we have a collective responsibity approach to software development," ask your self - "really and who do ask if they know what they doing?"

Bridge Building and Software Development

    There are vocal proponents that software development is unlike any other engineering process. This may be true, but for different reasons. I was reading a PhD Thesis from Robert Powell at the Stevens Institute of Technology. Powell's thesis is titled A Definition of High-Level Decisions in the Engineering of Systems.
    In the thesis was a brilliant set of statements. From the Standish reports (which of course have statistical confidence interval issues), approximately 85% of IT project fall short of achieving complete success. The problem with Standish of course is "success" is defined as On Budget, On Schedule. It does not take into account the other variables of a project. But that's another topic. I want to get to the bridge building processes.
    In the Standish report the failures are attributed to Human factors as opposed to Technology. In 1986 Alfred Spector, president of TransArc co-authored a paper comparing bridge building with to software development. Spector was the former Director of the Information Technology Center, Carnegie Mellon and is now a VP at Google.

    Bridges are normally built on time, on budget. Software never comes in on time or on budget. Spector found when a bridges falls down (or has technical and business difficulties) it is investigated, and a report is written on the cause of the failure. The resulting information is used to produce or refine the decision or decisions in an attempt to prevent recurrence of similar failures. This report becomes part of an architecture that is used to guide future decisions for successful bridge construction.

    However, in the computer industry failures are covered up, ignored, and or rationalized, which may be due to the absence of procedures for analyzing failures.

    Subsequently, due to he lack of a rational explicit process, the same mistakes continue to occur and negatively impact the success of software development projects. Because of human failings, critical information is lost, decision making becomes difficult, and mistakes are repeated. It is the repetition of mistakes and the occurrence of new ones, because of improper decision making, that result in canceled projects, cost overruns, time overruns, and failure to provide expected features.

A second reference is a US Air Force study stating three common reasons for software system development failure:

• Risks associated with teams - if the team of developers, acquirers, end user, and system maintainers had not worked together before and did not learn to communicate effectively, they were not likely to develop a successful system.
  
• Risk associated with technology - Teams that pursued a new technical approach (for
  example, the first foray into client-server computing) found that the lack of experience
  with a new technology, architecture, or development approach contributed to failure.
  
• Risks associated with requirements - the most often-cited reason for failure
  was poor management of requirements characterized by frequently changing
  requirements, requirements that were not well understood, and requirements proliferation

A KPMG report cites the principal reasons for failure among IT projects as poor project planning.

No project can really get off the ground without a valid plan. The project plan reflects many decisions made during the development process (e.g., compatible tasks, schedule, budgets, defined and acceptable risks, etc.) and a poor plan is simply a reflection of poor decision making.

So in the end it's not about developing the software. It's not about applying one method over another. It's about project planning, good requirements, and having teams that can work together with the technology selected for the project.

When someone says bridges are not software, they're right. Maybe software development should learn from bridge building and stop doing poor engineering processes. With the advent of COTS products as the basis of most Enterprise IT, it's time to stop making software "special."

If the software development business doesn't start behaving like they are building bridges - or other projects that increase the body of knowledge from their failures - no "magic beans" are going to improve the outcomes.

Following the PM Method

Ron Rosenhead posted a quote "Strict adherence to the project management methodology is more important than the delivering the project.
    At first I thought - naw that can't be the right way to go. Then a second later I thought, "yes that's exactly what we do."
    One starting point is to close the loop with the concept that "We adhere to the project management method over delivering the project outcomes" This of course depends on the domain and context:

• In FAR (Federal Acquisition Regulation) program, adherence to the PM method is mandated.
• At the enterprise project level for IT, adherence to PM method is usually mandated by the IT Governance policy

Now before all the agilest start foaming at the mouth, this approach is highly domain and context sensitive. Here's why:

• If I have a portfolio of projects in IT or a Program in defense then the underlying programmatic management processes need to be similar in some way to make comparisons of the performance of projects in the portfolio.
• On Defense and Space programs within the same company or possibly in the same business unit, business unit performance measures need to have similar underlying methods - again to have the same units of measure for all project or programs in the business unit.
• If I'm burning my own money (figuratively) then adhering to a consistent method over time is probably not that interesting. If I'm spending the public's money it's a different issue. By public this can mean tax payer - any tax payer - federal, state, local. Or stockholder.
• I'll go out on a limb a say that many of the "method wars" make no mention of the funding sources. They seem to be all about the developer or the individual.

In the end having one PM method works IF there are graded version of the PM method. These means:

• Methods are subsets of the largest set of process areas.
• Brookhaven National Laboratory produced a  Graded Application of Project Management method based on Department of Energy O413.3 and PMBOK that we used at Rocky Flats.
• This graded approach allows tailoring of the PM processes to fit the needs of the project.

In the end the PM method in an enterprise or large project environment should be followed OVER getting the work out the door. Getting the work out the door is necessary but not sufficient for sustainable performance of a project-centric business.

Specifications

    For all of us looking for specifications and documents that are usually buried in some web site or worse, available for a price, there's a source - EverySpec.
    Some things that were only available at IHS can be found there. The mythical ANSI/EIA-748-B is not.

Earned Value Issue of SoftwareTech

SoftwareTech is magazine from the Data & Analysis Center for Software, US Department of Defense, Rome Air Force Based, Rome, NY. The current edition is focused on Earned Value Management. There is one article on using earned value concepts in agile projects. Charts for Earned Value and Planned Value are used to show how the agile project is progressing. This approach is fairly benign in that it assumes "level of effort" consumption of labor resources, so no S-Curve is needed. The 0/100 percent completion is the right approach for EV, and the fixed periods of performance make it easy to compute the performance indicies.
    Paul Solomon has an article on "Applying Earned Value Management to Software Intensive Programs," that describes the more robust used of EV, using his Performance-Based Earned Value^tm (PB-EV) approach. PB-EV is one of the approaches we use in our Deliverables Based Planning^sm program management method as it is applied to DoD programs.
    This journal is free from DACS.

The other magazine that arrived in the mail today is Defense AT&L. This is published by the Defense Acquisition University. The DAU site has many useful sources for project and program management as well as the "human side" of these activities. This months edition is dedicated to just that "It's About People."

The Peter Principle Lives

Bob Sutton's Blog has a nice piece applicable to nearly every malady in today's headlines, from the financial crisis to failed project management.

In Praise of Simple Competence

Management of Projects

The conventional definition of management is...

To control and direct; to administer; to treat, as a person, with caution and judgment

The Software Engineering Institute's People Capability Maturity Model Integrated (P-CMMI) definition is...

To accept stewardship of a resource; to develop; to optimize the conditions affecting success

Restating the Obvious

Through a series of posts I came across an interesting site. www.typealyzer.com which will tell you what Meyers Briggs type you are from reading your blog.
    Well guess what, I'm INTJ.

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be physically hesitant to try new things.
The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communicating their visions to other people and need to learn patience and use concrete examples. Since they are extremely good at concentrating they often have no trouble working alone.

    Not so sure about the theoretical part, since I earned my living in the science world as an experimentalist. Not too interested in new things these days. But at 61, I've had more then enough excitement to date.
    Pointed it at my home site www.niwotridge.com (ISTJ: The Duty Fulfillers) and or firms site www.lewisandfowler.com (ESTJ: Guardians). Another guardian is Lockheed Martin, one of our clients.

SEI Membership

    The Software Engineering Institute (www.sei.cmu.edu) is a source of the Capability Maturity Model Integrated (CMMI). CMMI is the basis of a process improvement framework used with success in many domains. There are other Matrity Models, including OGC's Project, Program, Portfolio Management Maturity Model (P3M3).
    SEI used to have a free membership. Now it costs. But there is still a free membership for veterans. You need to go to LinkedIn, look for the SEI Group, sign up. You'll get a message back - "this is a members only group," with a link to the applciation.
    Fill out the application, attach your DD214 and fax or mail it in. You'll receive a very nice email with the account information. Thanks to a work collegue who is a Marine - Semper Fi Mac - for pointing this out to us old guys.

Open Journals

Came across a useful link in my travels today looking for Earned Value and Earned Schedule papers

Directory of Open Access Journals

Why I'm Not a PMP

Raven Young posted a link observing my membership in PMI but no PMP after my name. I am a member of the ACM, IEEE, its Computer Society, American Physical Society and INCOSE. Each of these professional organizations has a technical journal that adds value to my work activities. I also subscribe to Scientific American, American Scientist, Sky and Telescope, and Aviation Week and Space Technology  and Physics Today along with Road, VeloNews, Bicycle, National Geographic, and a variety of news magazines. I'm the son of a University Librarian. I'm genetically wired to be a knowledge hound. I connect easily with the "theory of ideas" types. This was probably the reason why I wasn't a raving success on the PhD qualifier exam - not a source of truely orginal ideas needed to move up the food chain of particle physics.

But in the end I'm not a PMP.

Why?

I've never really given it much thought. I know PMP's, I work with PMP's, I've hired PMs with PMP's. Nothing in the PMBOK seems at odds with how I view the world of project management. For me personally PMBOK doesn't really have a lot to say about the project processes I use every day. In fact the DoD version of PMBOK pretty much replaces most of PMBOK verbiage with its own, keeping the chapter titles and overall structure.

I guess in the end the PMP moniker doesn't appeal to me that much. It seems to be a "gate keeping" type badge. I once tried to get grandfathered in as a Professional Control Systems Engineer. But my job changed and I didn't have enough practical hours to qualify in California and was sent to work in Ohio on a flight controls systems and lost interest. I know PE Structure engineers, I have several colleagues in Canada with PEs and their "iron ring." This idea is really useful - get a degree in some kind of engineering, do semesters of internship, write a serious paper in your senior year and take the PE test and you get to graduate. You're a practicing engineering as a new graduate. Great concept.

Me, I was a physics major who could program real time experiments, and then learned to manage software projects, got an MBA/Systems Engineering and moved into management. So what would a PMP offer me? Good question:

• Professional status - maybe if the PMP was in fact a Professional Engineering certification like the state administered PE
• Skills - not much to do there since the PMBOK and PMP are pretty rudimentary compared to the full up EV/IMP/IMS performance based contracts I work on
• New knowledge - not much there either compared to our multiple location, multiple IPT fully integrated weekly earned value execution programs

I'm not saying in any way I have skills and knowledge that are unique or special. I work for and with  planners, cost engineers, project and program managers that have 2 to 3 decades of experience. It's humbling to sit in a room discussing an issue and have someone comment about how that same problem was solved 23 years ago using a manual technique - everyone remember C/SCSC and line of balance?

So far I've not seen the need...or the advantage to my career... or that it distinguishes the holder in anyway dealing with the practical aspects of managing projects for money.