PMI has a term for it:

Progressive Elaboration

MSF, Martin Fowler (this guy is amazing), and XP have a term for it:

Continuous Integration

George has a term for it:

Iterative Refinement

It reduces Risk!

It prevents Scope Creep!

It keeps your application fresh!

It is a license to toss BUF requirements!

It makes User Stories a viable alternative to Use Cases!

It obviates the antiquity of the conceptual Waterfall Lifecycle!

What is it? Well, there are three names for it above. What’s so complicated? We have the terminology… we have some of the benefits… it is clear that something very distinct is rue:

Project Managers are Ninjas of the IT world. They are the herders of cats, the keepers of the wind, and the snake oil salesmen that transfix small camps of people.

These terms are a way of describing the obvious; a project at inception is not the same project at delivery. In fact, the need is often not known until the solution is explored.

I am reminded of the law which states that you cannot observe a thing without affecting that thing. I am reminded of Pandora, and her box. I think it inevitable that in order to prove it’s own validity, any discipline will attempt to wrap it’s tenets in terms that roll off of your tongue as naturally as a drip of drool as you stare at The Delicious Answer. It is enticing, no? Progressive Elaboration. Iterative Refinement. Continuous Integration.

We’ll figure this stuff out as we go, because we can’t do it all now. Doesn’t even make sense to try.

Indeed, as projects unfold, the initial scope and even specifications will morph into something else. You’ll have iterations, Scope Change Request or simply Scope Changes. There will be pieces of javascript left dangling until someone sweeps them away. There are a variety of forces acting on your embryonic solution. There are people: people with opinions, and titles like Chief Operations Officer or Lead Architect or Doctor. There are technological issues, such as compatibility or expense. These are generally the elements of the classic Tripe Constraint. It all boils down to:

Time

Scope

Cost

At least, that’s the way it is generally presented. I have issues with codification of the dynamic – but it is more a philosophical one than a practical one, and we must be practical.

And no matter what you call it, the fact that projects have elements as mercurial as the face of a madman, and facets that shift like the tectonic plates, the fact is that the world is a malleable place, and we cannot herd cats, capture the wind, or disappear in a cloud of smoke. We have to work like a sonuvagun to be reasonably accurate, until we are almost done. We have to draw the target before we can hit it, and f the target is moved, we need to realign. We cannot shift direction at right angles in mid-air, like a UFO. We are required to Progressively Elaborate. Each project is a new land and with each effort we both accomplish the completion of a task and fail to explore an alternative. We Continuously Integrate, because as we go along the world goes along with us and we become aware of where we are and even what we are doing. We gain a momentum, and as scientists discover that photons will scatter in a way they can codify and use as an imaging tool called Ramen Scattering, delving deeper and deeper into the nanoworld, wrapping real phenomenon in ever-changing definitions – Project Managers Progressively Elaborate just like technology and the rest of the world does.

You need a new feature? File a Scope Change Request.

You have exhausted your budget? Get more money, move some money around, expect less, or expect inferior quality.

It’s not so much about the trees as it is about the forest. If you have a forest that you like, the trees are okay.

What I am saying is that among all the ceremonious PHASES and TRACKS and KNOWLEDGE AREAS, there is a fundamental truth; ceremony is created for a reason. When something happens naturally, or according to plan, there is usually a notable lack of ceremony. You can call it the Define Phase – it is figuring out what you are going to build. You can call it Monitoring and Controlling – it is babysitting the build. You can call it Deployment – it is turning the stuff on and making sure it works.

I submit that the execution of an IT project is a succession of discreet steps, named for sake of conversation and generalization. We speak in Universals, but the world is made of particulars. Projects have Phases, but they exist as discreet movements towards an end. Agility allows for this, but isn’t Agility just a way of supporting what we already knew?

We don’t know everything. Definitions change.

Look at the world of real science. First, space was made of ether. We used to have humours in our blood and in the air. The smallest particle of matter was the atom…no wait – the electron… no wait – the quark… no wait – the so on and yet to be so forth…

But do not waste your time thinking about that. You should be studying for your PMP. It is worth money to you, and you need those checkpoints and milestones and exit gates to CYA. As project managers, we have to be able to point towards something that says we know what we are doing. People don’t want to hire you or put you in charge of their projects unless you can demonstrate in some definitive way that you have a good understanding of how to manage a project and make it happen, keep it controlled, deliver with no cataclysmic surprises. You are to be a practioner of the discipline of measured progress, the keeper of the key to delivery and the guide for the blind amorphous beast.

DON’T FORGET TO HAVE A RISK MANAGEMENT PLAN!

When I worked construction, in my early teens (Dad was the company owner, so I worked since I could hold a wrench), all the guys would come to the shop before the sun was up and make sure their trucks were loaded before heading off to their job sites. The overhead doors stayed open – even in the dead of winter – while the same little huddle took place every morning. There was no place to sit in that shop, unless you wanted to get a metal burr in your bum. We stood. In the biting cold. We went over what we needed for the day, where we were going, what issues we anticipated, and swore at each other. It was a brief meeting, to the point, and we did it for a reason.

Minus the coffee and cursing, this was a scrum. Imagine that. It strikes me funny. We didn’t even call it Extreme Construction (XC).

With measured discipline and a good degree of mirthful abandon, you can enjoy corralling the ambiguous need and forging a hard coded solution. You can be an illusionist, making ideas manifest as reality and capturing the wind while defining those very elements that you demonstrate mastery of. It is an awesome thing to do, and it is impossible to be certified in any meaningful way in regard to this. There are tools and there are best practices, but there is also the x factor – and there is no training for that. There is only the ability to change, shift, adjust, and learn. It is a very human thing: Agility.

Best,

Josh

Being a PM can be like being a General Contractor. Obviously, there is a very direct relationship. I know this is not going to win a Pulitzer. General Contractors have PMs. Still, there is another shade of metaphor here and I am going for with this impromptu post. See below, and know that there are definitely compound meanings in these bulleted items.

• You come across projects at various stages of completion and need to either pick up where the other folks left off, recommend a new direction, or tear everything down and start over, salvaging whatever you can. Sometimes, things are just bad, dangerous or otherwise not suitable for moving forward with. These are checkpoints (MSF) or milestones (PMI) or plain old sniff tests (life).

• Inception may occur when an effort is born anew. This is a common slipping point for PMs, I think. Sometimes you move faster by slowing down. Your effort has to be feasable (AUP) for it to be a true effort and not a fib.

• You need to keep the final goal in mind (project charter, scope doc, whatever you use), but approach the effort in a systematic and intelligent manner, one step at a time, one phase at a time, overlapping where possible and acting as a conductor, allocating resources and deallocating as needed (your SDLC is NOT your PLC but your PLC should be aware of your SDLC).

• You need to watch what you are spending on subcontractors. You have a budget. If you have money left over, it’s a win. Unless you are grant-funded. In that case, spend all you can because if you don’t, you won’t get it next time. You must have a cousin who knows how to lay blacktop, no?

• You have to approach each job as an individual effort. You can’t show up at every job site with a hammer and jigsaw and expect to be able to handle whatever comes your way. Agility is key. Be ready to get ready, know what ready is, but be mindful of the clock. You need to expect the unexpected, but realize there is no drama in it.

• You have to be aware of risks, like things falling and hurting someone, the weather, and neighborhood kids stealing the freshly planted landscaping. No, I never did that as a kid. I was very well-behaved. Once, though, I did see a General Contractor who left his pet pit bull in houses he was building. He had a mitigation plan, of sorts. If you need a quick template, you can have mine.

• You can drive around with a giant toolbox (maybe it says PMP on the side?), but to do that, you need a giant truck. You need a place to park that giant truck. You need to buy lots of gas for the truck. Big trucks are overhead, like big toolboxes. If you have a giant truck and the facilities to maintain it, great. If not, you will have to visit the project and come back with carefully chosen tools. If you know it is an electrical job, you’ll likely leave the jigsaw at home and bring other, more task-specific stuff along. I don’t know what that would be for an electrical job. I worked with pipe when I was younger, but never electricity. I am colorblind. It would be dangerous.

• If you know you are going to have to put 3 coats of paint on the house because of the existing color, you plan for 3 coats of paint. You make sure you have purchased enough, you make sure that you know how long it will take to dry, etc. You plan for iterations of painting. You don’t plan to “paint”.

• If you are doing a custom job, your client will be visiting. At least, I hope they do. I would. You should encourage this. You should involve them in the process, from drawing the blueprint and walking them through their dream home to showing them samples of travertine for the kitchen.

I have been watching Designed to Sell.

I am a Geek.

But, I am a BIG geek, so I get away with it .

Thanks,

Josh

PMP/PMI has has turned into one of those things that HR people put on the job description just because they assume it is a de facto standard. It is not. In fact, of all the PMs I have worked with, none of the top 5 are PMPs. Quite a few of the bottom 5, however, are. It is one thing to memorize the PMBOK. It is another thing to understand it. And it is yet another thing to manage a software project within an organization that uses an iterative, agile, spiral, V-model, or really any sort of SDLC that is still viable these days. I know some people claim they use waterfall, but I have yet to even hear of one project involving new development that went along the waterfall route cleanly.

Of course, I am assuming here that the IT organization is not hiring a PM to sit behind a desk with a .mpp file and move colored blocks around on their screen. I am assuming that the PM is also a BA, technically-aware, and at times client-facing. In software – especially custom software – your PM has to be these things. Software is a unique animal. Custom software is yet another.

A PMP is, in my opinion, less useful on a software project than a plain old PM who has also played Scrum Master for a couple weeks, or is familiar with MSF, AUP, RUP, or anything else software-related. I would rather see a PM draw an interative lifecycle for me than list the entirety of the inputs for the Monitoring and Controlling phase. At work, we do work.
I didn’t post this because I do not have my PMP or because I am looking for a job. It just irks me, a bit, because people could see such greater results if they only took the time to understand their situation and the tools available to them. PMP/PMI is great, but it is not software-specific. It has tremendous overhead. It is, in many cases, a paper certification.

If there are software-specific approaches out there (that are proven and are battle-tested), why not consider their influence foremost?

Best,

Josh

Preface: 012210 -  This specifically ignores prioritization and instead explores the MoSCoW method. Figured that was worth mentioning, when I went back and read it. Thanks!

—

This article has been born from a trend that I have seen gain traction over the past few years. People are building requirements matrices of sorts, and they are coming with MoCSoW associations. I think there is a disconnect, and I want to address it.

A requirement is something that is required. The term ‘requirements‘ has taken on a new meaning within software projects, but I want to address that and try to make a case for logic here.

MoSCoW refers to a method in which System features are either MUST haves (absolutely needed), SHOULD have (we wouldnt die without it, but it should be there), COULD have (we will see as we go along how likely it is), or WON’T have (determined to be out of scope, part of V2, or just erroneous).

A requirement is not something that is “nice to have”, or “will not” be had. If it is required, it is needed. Otherwise, it would not be called a requirement. It would be called a goal, an ambition, or a hope, dream, fantasy, etc…

We write requirements as such: “The System SHALL do X, Y, or Z”. We use short, declarative statements. We dot notate TRUTHS about the System. We assert. A requirements document is a very assertive document. It reads like a dictum. It is a dictum.

We do not say, “The System MIGHT do A, B, or C” or “The System WONT make us toast in the morning.”

Issues regarding priority and the inclusion or exclusion of functionality are scope issues, not requirements issues. If we are developing against requirements, we better know what we are requiring. See the image on my homepage to get a sense of what happens all too often.

Now, it is perfectly sensible to use MoSCoW as a way to prioritize features, functionality, or any given aspect of the System. This happens during Discovery, Inception, Envisioning, or whatever your chosen approach calls that part of the project where you figure out what it is that you are building.

However, when have defined requirements, you have gone through a lot of discovery. You have the ingredients of a contract. This is where I think people get confused. A contract does not have to be like the Ten Commandments, etched in stone. It can accomodate best practices.

The contract, although binding, can and should include the provisions associated with iterative developement. If you do not assume that there will be changes in a software project’s scope, you are assuming that you know everything about the project at the onset. This is never the case. If you have ever written a scope document for a project of significant size and delivered without making any changes, I want to know about it. You will be the only one in the world who has pulled that off. You would have to be some sort of BA super hero. I know they are out there… I have just yet to meet one.

Now, many of us are practioners of some form of Agile SDLC or methodology, and we know that scope will change. This does not mean that our contracts read, “The System will consist of functionality that we aren’t quite clear on yet, but we will figure it out as we go…” It means that the client is aware of and understands that AUP (my favorite right now) affords us the ability to deliver what the client really wants without asking them to make decisions they are not equipped to.

Initial scoping can be, and will be, fuzzy around the edges. However, when writing requirements, there is no fuzziness. If a requirement changes, that potentially calls for a scope change. That calls for a process that is very easily woven into Agile development and is indeed assumed by it. Having defined requirements does not inhibit Agility. It engages Agility.

I just wanted to get that off my chest. A requirement is REQUIRED until it is no longer a requirement.

MoSCoW classification belongs in scoping, context diagramming, brainstorming, and the like. It does not belong in requirements. Your requirements are your rock. You cannot have wishy-washy requirements or you will be forever developing against nebulous ambitions. Let’s build Systems the best way that we can, and if we can, overdeliver. PMI calls it gold-plating, and warns against it. PMI is not a good software methodology.

In an iterative or Agile environment, gold-plating goes away and what emerges is client-focused, top-notch software, aimed at exceeding client expectations.

And still, a REQUIREMENT is required. If it cannot be done, it is not a “nice to have” – it is a headache for the Project Manager and probably a series of meetings and excuses. This is the only way I know to honestly undertake the task of building software. Be truthful, be positive, and be Agile – but focused on and true to the peculiar discipline we call a project.

Thanks,

Josh

There are a million flavors of Issue and Task Logs. There are also a lot of nice software products out there to help you track bugs, manage work packages, and keep a tight grip on your project. However, some organizations have young PM/BA efforts and cannot afford or do not quite yet have the need for something robust and keep a tight grip on your project. However, some organizations have young PM/BA efforts and cannot afford or do not quite yet have the need for something robust and comprehensive. Sometimes you have a conference call and six or seven pages of notes that need to be translated into something portable and understandable. In that case, I recommend Excel.

This particular .xls is something I just created off the cuff. It would be most suitable for a small team that had scrum meetings in the morning (even if they are not called scrum meetings and people just get in a room and talk). You may have no use for the ‘Severity” column. You may want to put a lot more detail in the “Notes” field. The point is, keep it modular, keep it simple, keep it unambiguous, and let your team dictate how it is structured.

This Issue/Task Log would be one tab in an Excel workbook. In some cases, I may have a seperate worksheet within the workbook for UAT tracking, Task Identification, and Risk Management. Most likely, I will break the more unruly sections out into their own workbook or even Word document. This is documentation on a budget. I know there are pretty slick tools out there, but Excel works just fine for small projects. Of course, once the project hits a certain size, you will want to implement Bugzilla or some other bug tracking software. What I depict here would not be relevant for a shop that is running Team Foundation Server or other project-oriented development tools/environments.

When issues arise, it is not always apparent if it is a bug, a question, a point of ambiguity, or something out of scope. I like this format because the initial page can capture anything, and it allows you to remain agile.

The Task List is much more stringent, and if you are maintaining it manually you have to be disciplined. If you slack off for even a few days, it may be impossible to adhere to traceability practices. That is what this is all about, really: traceability. These types of manual documents are as useful at the project’s end as they are during execution.

Items move from Open to QA as they are addressed and tested at least briefly by someone on the team. I generally have a UAT tab to track testing, and work on it with the client in a GoToMeeting or in person. I actually create a new tab for each UAT session for accountability, to reveal flaws in code, and because really, every few sessions you should go back and retest EVERYTHING. Sometimes a fix will break something else, as you know.

In this particular example, as issues pass UAT, they move from QA to Closed, and get pushed down the bottom of the list, greyed out, and segregated. This is an arbitrary way of maintaining the document, and if I am going to be honest, it does not particularly appeal to me. Still, this document is not only (or even mostly) for me. It is for the team. One of the developers gets thrown by not having open items together in one lump. They freak out about it. I personally do not like moving the items. It makes Issue “6″ harder to find because the Excel row numbers are confusing and because unless issue numbers are sequential, I don’t know any easy way to order them.

This, however, is an example of a small project, and if the team likes it, I will produce and maintain it.

The filename is always at the top. I like to do this. The “Effort Identifier” could be the project name, or something like “May Maintenance”.

Don’t forget that Action Items become Agenda Items pretty happily and that depending upon the buzzwords at your organiztion,”Severity” can become “Prioirity”, have a MoSCoW status, or something else. This is built to be tweaked. Adaptive.

I am sure you will notice that I reference other documents within this worksheet. If you do not have a comprehensive tool, you will have to create one with what you do have. This allows for Object-Oriented Documentation. The Risk Assessment Worksheet will probably live in a distinct Excel worksheet, because it will undergo many iterations and will likely be in front of a different audience than this document. Please see my post about Risk Management for a nice Risk Management template that is easy for almost all audiences to understand.

The worksheet I show above is not the only way to track issues, and it is certainly not the best, but in a pinch, you can do something similar. I dont imagine there is anything very novel in this post, but I hope someone finds it useful. Keeping track of tasks does not have to be difficult.

If for some reason you wanted to download this little template, you can do so by clicking the Simple Issue Log link.

Best,

Josh

Thoughts on 7 Good Practices for Modeling Software Requirements:

From http://www.stsc.hill.af.mil/crosstalk/2008/03/ – these are 7 “Good Practices for Modeling Software Requirements”:

I like the spirit of this. But for those who are in an Agile or XP environment, or for those who follow MSF, AUP, or other iterative frameworks, there are some things to consider. I am going to bring up some, but certainly not all, of these sorts of issues.

In regard to 1. BRUF (Big Requirements Up Front) is not only time consuming and costly, but often somewhat wasteful. Requirements change as your stakeholders and clients learn about what they are getting. Most of the time, as a software consultant, part of your job is to help the client realize their vision or solve their problem via technology. This is normally an iterative process whether you approach it that way or not. If you define scope as the 10,000 ft. view of the project (perhaps a simple Context Diagram), then I like this very much. However, the author of this chart suggests doing this to ward off scope creep. Scope creep is GOING to happen. If it is billable or not is one question, but if it is going to happen is another. It is going to happen.

In regard to 2. Again, I have stressed this elsewhere in my blog, but I believe that you use what is useful. Documentation can drown you fairly easily. Keep it light, Barely Good Enough, and malleable.

In regard to 3. Repeat of #2. If your developers have no idea what a State Machine diagram is, you are going to have to work with what they do know. Most folks can get the hang of simple Activity Diagrams fairly easily. In my experience, you cannot throw all these models on the table and have everyone respond (in a positive way). New concepts need to be introduced slowly, and as they alleviate pain points. I have seen many a PM fail as they come to an organization with a portfolio of templates. Templates, even, usually need to be customized. We are lucky in this field; all of our tools are malleable. That is, unless you are using something like Rational, in which case you can find malleability within a gargantuan and robust legacy.

In regard to 4. I wholeheartedly agree, but wonder how this relates to the first item on the list. Your scope will speak to your requirements, and then, vice versa. This is iterative: RIP, JAD, what have you.

In regard to 5. This presupposes BRUF, to a degree, or at least some kind of system for documenting requirements traceability. Lots of places I have worked had MS Office as their PM tool suite (minus MS Project). You can do this with Excel (and I really like Excel for doing this), but it is time consuming and might not always be required -particularly if you are in an Agile or XP environment. The key here, I think, is in managing traceability and not breaking the thread.

In regard to 6. I like this one.

In regard to 7. There is not always time for this. At the end of each timebox or build, or at each checkpoint or milestone, there is often a sense of urgency. That is one of the reasons to implement an iterative development cycle; it keeps everyone from becoming complacent.

BTW – Timeboxes that begin and end midweek have been most effective, in my experience. Fridays will kill you, and Mondays are bad days to start.

Thank you,

Josh