If anything, some of my redirects are not working.

LiquidWeb will save me, as usual.

Why I ignore the “if it ain’t broke don’t fix it” tenet when it comes to gadgets and WP is beyond me…

Have a great day.

Josh

And yes, I also think my little screencasts are silly. Another coming soon.

So, seven percent of what is scoped up front winds up being something that users engage (when the project is considered SUCCESSFUL).

I am curious if these projects are new efforts, migrations, or what, however. I think that might be very germane.

Best,

Josh

There seems to be a pretty decent need for a generic RFP template, so I thought I would fire one off this afternoon as I attempt to rest my little brain here in Miami (where the people are way nicer than I was told they are).

• X. Some sort of Confidentiaity Agreement may come before the RFP delivery. I have seen these IN the RFP, but come on… the RFP is in their hands at that point.

• 1. Executive Summary - Formal declaration of the fact that this is, indeed, an RFP.

• 2. Organizational Summary - What is the organization’s history?

• 3. Organizational Contacts - Who is the internal PM, Product Owner, other key Stakeholders? At this point, there is no need to give contact information for anyone who you do not want to be contacted.

• 4. Project Summary - What is this project/effort? Short and sweet. A paragraph or two.

• 5. Timeline - When is the RFP issued? When are questions due? When will responses be sent? When will final proposals be due? When will a vendor be selected and when will be project/effort begin? If there is a due date or a time the project must be completed by, you might want to note it here and let the vendors tell you that you are crazy.

• 6. Terms and Conditions / Glossary – What verbiage is not immediately intuitive or contextual in a way that needs to be explicated? Also, you might want to mention that the RFP is not to be passed around or presented to 3rd parties.

• 7. Design Requirements - Reference to a Style Guide if there is one, and depending on if the project involves design work, as much as can possibly be communicated in regard to desired look and feel. You might want to mention sites that are particularly well-liked, competitor sites, etc. Also, do you expect to see 3 versions of a proposed homepage, followed by X rounds of review? State this.

• 8. Functional Requirements - A big list of dot notated “The System shall…” statements. Corresponding MoSCoW assignation may be useful, or some type of priority codification.

• 9. System Requirements - Are there any? Scalability, for instance?

• 10. Subsystem or Integration Requirements – Any special workflows involved? Any integration mandated? If you are migrating data, mention it here. You might want to provide a data model (high level) along with a general assessment of the data’s condition. What DB is is coming from and what DB is it going to? Alternatively, what other Systems will be integrated and what do those integration points look like (high-level UML might be useful here).

• 11. Project Milestones - For the Vendor to posit delivery dates against.

• 12. Request for Platform, SDLC, and/or PM Methodology Clarification – How are they going to build it? On what? What process do they use and can they describe what the experience will be like? Iterative? Hope so.

• 13. Restrictions and Limitations - Anything that might speak to this could be helpful.

• 14. Specific Questions - Good place to ask outright whatever it is that is not a requirement but needs to be asked, like “Have you ever done anything remotely similar to this before?” Or, “How much of this work will take place on US soil?” Or, “What will our points of contact be, what will our escalation protocol be, what will our change. This part can also function as an RFI (Request for Information) of sorts, if you have a general idea about something you need improvement on or help with but are not sure how to accomplish the goal.

• 15. Point of Contact for RFP Questions and Submission - Self explanatory, but it is important that this person does not answer any questions without taking the protocol into consideration. Also, the protocol should have a mandatory end date for questions to be submitted in writing. Anything after that will go unread. If a vendor submits questions a day late, chances are they are short on resources (or just sloppy). If a vendor cannot submit by the mandated date, they should make that clear. Generally, I like to give vendors a week or two’s notice that they will be getting the RFP and then, depending on the scope, 2-3 weeks to respond with questions and another 2-3 weeks to write up and deliver their proposal.

The quality of your RFP will usually speak to the quality of the proposals you receive. It is also advantageous to put some work into fleshing out initial requirements so the vendor can respond, specifically, to what you know you need. This up front work is subject to change, but it provides a rough idea of initial scope and vendors who simply cannot create a J2EE application that integrates Oracle with Informix and Google Gears will know to bail early. Also, if you are able to toss a nice UML diagram in your RFP here and there, the vendor will take care to understand their audience is not entirely unaware of BS.

If you need help writing your RFP, contact me. This is in no way intended to be a catch-all Table of Contents. Like every project, every RFP is at least a little different. It is all about delivering good, working software. This process starts with a firm engagement with the vendor.

Best,

Josh Milane

Certification in Agile Software Management

Cheers to this organization. Important lessons taught there, methinks.

Best,

Josh Milane

Okay, Barely Good Enough (see previous posts) is not insightful. I realized this suddenly, while thinking of how insightful it is. It is a cool concept but it is not a new concept. It is (as things are so often in the PM/SD world), repackaged and dressed up basics. It is not even Barely Good Enough. It is correct. There is no element of worth here, no judgement as to virtue or value. It is only articulated to clue people into what they might be doing wrong, and in at least one case, cause a poor unfortunate PMP to UNlearn all she had learned in an effort to become the agile magician she wanted to be.

If a shirt fits, it does not fit Barely Good Enough. If a map gets me from A to B in the most efficient (or pleasing, depending on my intent) way possible, it is not Barely Good Enough. These things are accurate. They are built to suit. They are correct. The world is custom. There are no Universals. I think this article may be barely good enough, but I know it will NOT be Barely Good Enough.

It is about the level of appropriate detail. Barely Good Enough as a mantra limits us. There is nothing wrong with thinking outside the box because you like what you do, or do not understand, or want to stir things up and keep them exciting.

I prefer appropriate and informed. Who are we to tell a Client, asking for a detailed WBS with float calculated, that it does not fit the model we use? They are the Client. We have to adapt to them and they are part of the team. Give and take, in an appropriate and informed manner. Maybe we ask why they want the WBS and can offer something else, or maybe we ask and then deliver. Either way, at least we are recognizing that things change, are dynamic, and that what works today might not work tomorrow. Is that not Agile? Is it not agile?

Keep Software Development human. Appropriate and informed. People over process. Intellect before expectations or presuppositions.

My 2 cents, today. Tomorrow, I change my mind again

Best,

Josh

I am even going to store my javascript in external files. The thing is going to be *clean*.

All my best,

Josh

I am sure that many of my readers have disappeared. More likely, they have just stopped checking in. I doubt any of you have spontaneously combusted, though it would be cool if you did. On video. No offense.

So here is my little nugget for the day: There is no such thing as Project Management.

Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “ScrumMaster” or any number of things related to IT project management. There is no Project Managment. There is task management. A project doesn’t keep changing – it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about in to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves, this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one for or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the Client try to determine what is fair. Wouldnt it be obvious?

An Agile SDLC removes the need for the “classic” PM and GANTT charts (thank God). However, a ScrumMaster is not enough (that’s another sham… pay $1200 and you get certified. No test, no obstacle course, just pay and get the stamp – and yet somehow, people eat it up). You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but (and this is not mandatory) the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you. You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. You have to really give a damn. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate. Or at least, it should be, in my opinion.

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I dont know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

Project Management isn’t about deadlines. It is about delivery. There is a big difference – just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task.This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templated approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your System, and in the end, the code is the functional spec (the path you take is the Path). I have found it best to let the Project reveal it’s Process.

Some scupltor I should know the name of but don’t said that he simply removed the excess marble from the statue. I like that ida. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.

“If you aren’t making mistakes, you’re not making enough decisions.”

I hope you are all well. Sorry I had to disable comments. I don’t like forcing people to register and to be honest, enough of you email me that I don’t see a need for comments.  I am quite happy to discuss, but that is because I like this stuff and want to learn something as often as possible. I do not use this blog to generate business, expressly. I use it to learn. It is, right now, part of my Process. You can say I am being very literal, but really… take a look at that GANTT chart from day 1 and compare it to the chart on day 100. Where is the project? In both, in between, and probably calling on the phone to find out when the mail merge feature is going to be ready because the bonus letters need to go out yesterday…

Best,

Josh

I am okay. Just very busy. However, I plan on starting back up with this blog thing tomorrow. I think Google un-blacklisted me finally. I need to check.

So, tomorrow: some scrum, some agility, some FDD/TDD, and some traceability. We will talk about building software the only way it really can be built: the way that works.

Again, thank you all. Talk soon. I will probably even re-enable comments once I upgrade WordPress AGAIN.

Best,

Josh

From what I can tell, a lemma is somthing that is assumed to be true so we can move forward under a given premise.

From Jeff Sutherland:

Wegner’s lemma - an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel’s theorem.

And now I have to mention Godel’s theorem. A theorem is a bit stronger than a Lemma. It has been banged on my scientists and other smart people, accepted as true or at least, having merit.

What’s with the fear of commitment? I guess you cannot apply Scrum principles to mathematics or logic. I am a big fan of logic (Ayer, especially), and so I understand. What I dig about Ayer is his principle of nonsense. I am sure if my old Professors heard me call it that they would choke on their oatmeal, but Ayer says that any statement that cannot be proven true or false is nonsensical, and that every statement that can be proven true is a tautology. Makes good, tight, sense to me.

This is not wholly irrelevant to software engineering. Bear with me.

I am going to cop out a little here, because it give me a headache, but you can read about Godel’s theorem here. It has been extended into many different verticals, disciplines, and websites. It seems to be just short of a Law. If it interests you to understand it’s complexities, please pursue the aforementioned link. You will find many other links there.

Below, you can read about how all this applies to your approach at scoping a software System and creating a proposal.

Lots of clients want a firm proposal with a firm, fixed price. They probably have experience with manufacturing processes, and so the Waterfall approach makes sense to them. This understandable. Software Engineering (new development), however, is not manufactuing. Unless you are prepared to eat potentially copious personhours of labor or fall short of customer expectations, you need to build a little slack into your proposal. This is classically done by using a multiplier, or by pricing iterations. Always seemed a little sneaky to me. The line item “Slack” reads like a copout.

Wegner’s lemma speaka to the validity of an iterative process of discover, code, deliver; indeed, it was one of the arguments used to support and ititiate the pursuit of Scrum before Scrum had been proven. Scrum is not new, contrary to popular belief. I mentioned in a previous post that we had something very similar to scrum at my family’s construction business, but it has been a software process for over ten years. It is finally getting real traction. If it did not work, you would not still be hearing about it. That’s the good thing about theories, I guess; if a theory proves to be bologna, you stop hearing about it pretty quickly.

You have three ways to approach a software proposal, if not more:

Give transparency into your process, deliver frequently, and this is pallatable. “Tust me” rarely works in the absence of a bullet-poof reputation of long-standing relationship.

There are really two options: commit to a Contract or commit to a Contracted System. A contract is not flexible and does not benefit anyone when it asks them to commit to ambiguity. A System is much more robust.

Here, we invoke Wegner’s lemma and our experience building software. Again, the requirements wind up being the source code.

Of course, I think the best is a combination approach. Do some initial requirements so you are not playing code cowboy. Then, engage the client in an iterative approach, grounded in a proven iterative methodology (like Scrum or XP or MSF) and keep communication open. If your client is able to see progress, they will not see your function as a black box. And if you make them the Product Owner, allow them to prioitize features (user stories), they will not have to ask why they do not have feature X yet. They will have asked for features D and E and delayed feature X in a calculated decision.

PS: As an asid, I’d like to mention, I am not really digging this new version of WordPress under FireFox. It is slow as anything. Under Opera, it seems a lot better.

Update 061108

Craig Brown is one of my favorite readers. He always has interesting comments (or he did, when I allowed comments… and there are 2 reasons I don’t anymore) and I wind up reading his blog and learning something when he engages me. That’s right Craig, you engaged me.

I want to respond to Craig directly because he is a smart guy that I respect although for all I know he has a suit made of human skin. I am not suggesting that people start contracting a system as much as I am suggesting that part of the client engagement include education and that *our* discipline stops being so defensive and starts getting down and dirty with the critics. I want real metrics. I want a marketing machine. I want what is best for humankind. I am a very sweet guy.

I have not seen software engineering really face, head-on, the world of clients who expect the more traditional manufacturing model. In contracting a system, I am suggesting that clients understand what they are contracting (in an Agile model) and I do think it is any more similar to “time and materials” than hiring any specialist is. Take a large investment firm. Go to them as a small software company and ask they to just trust you because you will be giving them frequent updates.

My doctor gave me frequent updates during my colonoscopy.

I invoke Wegner’s lemma and neglect to get into it deliberately. I maintain that project management and indeed software engineering as a whole are less science than art. Sure, we have color theory, but when it comes down to it, either you got it or you don’t (ability). We need more talented, open-minded, caring people who want to produce to the best of their abilities and not just slap “PMP” on the resume because it gets you a 20 percent higher salary and financial institutions wont talk to you without it. This will change SOON. Mark my words. We are going to see a hybrid of hybrid models. We are going to become trailblazers instead of pencil pushers.

BTW – I am not a pencil pusher. No Sir-ee Bob.

This applies to PMs, BAs, and software engineering firms. I do not understand Wegner’s lemma, but it has been fodder for the Agile community and I would like to see that stop. We do not need more pseudo-science or forced analogies, any more *almost* universal techniques, excuses, or approaches. We need to be honest and upfront and tell it like it is.

I invoke something I do not find palatable because I have a degree in philosophy, and it taught me one thing; you can talk theory all day, but at the end of the day, it is mental masturbation (excuse me) until you can actualize, materialize, and deliver something tangible. Tangible may take the shape of an idea. It may be a widget. But still, Wegner’s lemma does not manifest directly. We should not point to it for excuses.

Instead, we should progressively elaborate (sorry PMI) as a community and make change. Agilists become frustrated when you ask them “When and how much?” and I think it is a shame. We can give answers. We just cannot commit to a specific figure unless we

- are prepared to lose money
- pad our estimates heavily
- have done it before and are just generally amazing
- define scope and really insult the customer when our scope doc, that we knew was incomplete, falls short of being complete

Thanks, Craig.

Josh

Regardless, if you have a PDA or BlackBerry, you need to check out BeeJive simply because it is the most intuitive, easiest to install, best IM client I have found for handheld devices. The people there are cool, too.

Consider this a plug. I had an 8703e and now sport an 8830. I was going to get the Curve now that Verizon carries it, but I picked one up and ewwww it felt like a toy. I like my solid 8830. I was it was solid chrome and heavier, but it’s cool. As much as I will never go overseas with it, or at least have no intentions on going overseas with it, I will keep it. Sure, the Curve has a qwerty with space between the keys, but could they make those keys any smaller? My big fat thumbs can’t handle something so precise.

Anyhow, BeeJive. JiveTalk Mobile Messenger. Get it. They have it for iphones and have a Windows Mobile version getting ready for prime time.

Best,
Josh