WordPress Upgraded

There is no obvious reason to move to 2.9.1.

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.

Serial Requirements and Delivery

Stealing from Ambler here, but I have seen numbers MUCH lower in regard to the success of BRUF (big requirements up front) and if my word isn’t enough, and this colorful picture isn’t enough, just ask any IT PM or Manager what their experience is.

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

Easy RFP Template

Me again. There is nothing particularly *easy* about filling out this template, but the post title will probably get me some good organic search results.

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

Agile Software Certification

I do not normally put much value in certifications, but here is one you might want to check out;

Certification in Agile Software Management

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

Best,

Josh Milane

Agile vs. agile versus Versus

Oh man. Here I go again, contradicting myself. I love it. Means I am not becoming a cog.

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