MCF Solutions project kicks off new Home Base design

MCF Solutions

To kick off the new website, Home Base would like to showcase one of our current projects.  We are working with Urban Fox Design on a complete web redesign for a dental equipment sales company.  One of our strategic initiatives this year is to incorporate industry standard project management methodologies and a formal software development life cyle into small web development projects.

I will be quick since this is our first post and I obviously have a lot more work to do on the website.  The idea behind the project management methodology is to take the Project Management framework used on Ohio State’s Student Life enterprise level projects and scale it to an appropriate level of management on smaller web app projects.  I just got my PMP in December 2008 so all of the knowledge areas and process groups are fresh on my mind.  When you’re a small company and you’re dealing with projects that require less than 50 man hours and maybe four resources, you don’t want to over-manage.  I think this is the dilemma many process oriented managers face in a small business environment.  With MCF, and with all of our current projects, we focus on the following:

• Set, Manage, and Meet client expectations
• Frequently communicate status and progress
• Keep metrics to improve future projects and processes

All three focus areas above are applied to the project management triple constraints, which I think are worth another set of bullets:

• Cost
• Scope
• Schedule

Clearly communicating how much a project is going to cost, when it is going to get done, and exactly what a client can expect their new website to do up front is a huge part of our process.   It is very difficult to define scope and come up with accurate estimates early in projects, especially when you’re working with a client who doesn’t really know what they want, but the more time you spend early on defining and documenting scope, the better.  It is much better to frustrate a client by telling them something can’t be done up front than it is to tell them it can be done, have them spend a bunch of money on you, and then fail to deliver.  It also just straight up sucks when you have vague requirements and then you can’t justify charging more for scope creep.  Before I really embraced implementing project management methodologies, that happened to me more often than I’d like to admit.

This ties into our SDLC.  Home Base follows sort of a modified RUP/Agile Software Development Life Cycle.  We go through several iterations similar to Agile, but each iteration follows RUP-like process. I think I will save the specifics for a dedicated post, but we try to break each project into smaller parts, and then have clear phases with phase gate meetings within each mini-cycle.   For example, the MCF project has a bunch of static content and several dynamically driven components.  The project is broken into the following cycles:

1. Graphic Design – Site Template and Static Content
2. Admin Framework
3. Slide Show, events, contact us (dynamic content)
4. Case Studies

Each cycle essentially passes through requirements elicitation, design, development, quality assurance, and release to production.  I have fancy names for these phases, but I’ll save them for the longer post with plenty of pictures and diagrams.    In any case, we spend a lot of time on requirements and once Mark at MCF approves them, each cycle will enter development phase.   Progress can be monitored at http://dev.mcf-solutions.com.  The caveat is that there are no promises that anything in development will actually work. It’s my playground, and I can do what I want in there, damn it!

When I think I’m done with development for a cycle, I copy everything to QA at http://qa.mcf-solutions.com.  At Home Base, the lovely Brittany Baron will hopefully agree to be  our Quality Analyst.   Once she finds all of my major bugs (and I fix them), we ask the client to review and approve that the QA version of the site matches what they asked for in their requirements.  THIS IS IMPORTANT!! At this point, I often have clients say things like, “well I kind of thought the site should do this and not that.”  That’s great, and we can accomodate, but if we had good requirements and we can basically check off that the site meets them, these new requests equal change requests that we can charge for.  Not that I’m looking for new and improved ways to make money.  The later you make changes in a project, the bigger the impact.  I also don’t enjoy working for free.  Communicating this part of the puzzle up front usually causes clients to think a littly harder when coming up with their requirements.  Then I come closer to getting what they want the first time around, so they get their site done sooner and cheaper and everybody is happy!  If they really want to implement those changes, we can start the cycle over or decide to postpone changes for later.

If the client approves of what is in QA, we simply copy straight to production.

And that’s it!  Somehow I just wrapped up the process I’ve been thinking about for years in a nutshell! With MCF, the design cycle is currently moving from dev to QA.  While Brittany, Mark from MCF, and George from Urban Fox nit pick all of my minor design flaws, I am going to start work on filling in some of the admin framework in dev.  Hopefully this article gives some insight into our process.  I look forward to updating here as much as I can.