code prole


coding for the proletariat since 1977


I've been a consultant (more or less) since 1997. I've worked at a number of engagements both in the private and public sectors, each with their own flavor. The one overriding concern that always seems to get expressed badly is management of the consultant's time. Some engagements go so far as to require sign-in and sign-out sheets so that the "consultants" can be tracked. My current engagement allows the employees tremendous latitude regarding their work schedules. Some people are at work as early as 5:30 am, and consequently leave by 1:30 or 2:00 in the afternoon.

To a person the consultants I work with on this engagement are professionals. They all work hard, and we are meeting our goals in spite of politics and infighting between the various departments involved in the project. Some of us (myself included) are early risers and are at work by 6:30 or 7:00. Others don't arrive until 9:00 or later. However, the project manager (really an engagement manager) has decided that it doesn't "look good" for us to leave early on Fridays. You see we are contractually enjoined from working more than 40 hours per week. Arriving early and getting a running start on the week's tasks often results in 9 or 10 hours days. By Friday it is typical for me (and others) to only have a handful of billable hours left, and so we leave at 10 or 11 for the day.

Last week the engagement manager, in a fit of pique, sent an email to every consultant under his thumb demanding that we all be at work until 2:00 pm on Fridays from here on out. Reliable sources claim he threatened to set the time as late as 4:00 or 5:00. At first I was pissed that he was going to micromanage my time just so his company could "look" good. The engagement is struggling with large meaty problems like delivery dates, lack or requirements, and an inability of the client's management to keep their own process in check (resulting in a myriad of other problems). So naturally, instead of stepping up and demonstrating true professional mentoring we're going to instead focus on being at work until 2:00 pm on Fridays.


The silver lining in this cloud has been leaving work at 3:00 every day this week to ensure I'd have time for Friday. The extra hour at home every day is nice.


Filed under: Project Management

Trac Rockz

Recently, the pre-pre-startup team I am working with decided to start using Trac, from Edgewell Software. It is amazingly simple to use, and provides exactly the level of SCM and Project Management we want – minimal, agile, and unobtrusive.

Within minutes of having our site up we had modified the wiki, added new pages, and started tracking tasks through the ticket system.  With the integration to Subversion we now have an industrial strength SCM solution that just plain works. As a professional I am work within the confines of the clients local software environment, and  usually this means costly (in terms of both capital outlay and learning curve/backend maintenance) softwre suites. Henceforth, when I am asked for tools to use my answer will be Trac, Subversion, and MyEclipse.

Filed under: Project Management, Software

Pragmatic Bookshelf

Several years ago I discovered the seminal volume from Andrew Hunt and Dave Thomas, The Pragmatic Programmer: From Journeyman to Master, and it immediately became one of my favorite books about programming. In the last couple of years I have started to collect more and more “Pragmatic” books and each subsequent volume has been a delight. The topics, the coverage, the style, everything about Pragmatic Bookshelf is dead on target.

Over the weekend I picked up Ship It! A Practical Guide to Successful Software Projects, and just last week I purchased a beta copy of Pragmatic Ajax: A Web 2.0 Primer. The Ajax volume is excellent, even for a beta book, and I am enjoying learning a new UI skill. The description of Ship It! is what caught my eye, “This isn’t a book about a methodology. It’s better than that. It’s the stuff culled from a range of methodologies that together just works.”

I cannot recommend these books and this publisher enough. Quite simply some of the best technical volumes available today.

Filed under: Ajax, Pragmatic Bookshelf, Project Management

Extreme Makover: Software Edition

One of my new favorite shows is "Extreme Makeover: Home Edition." I like the idea of helping people who really need it, and building an entire house in seven days is a great hook for the show. As an enterprise software architect I am very intriqued by the amount of planning that must occur behind the scenes.

The current project team I am a part of has 17 resources assigned to it and it is nearly a fulltime task to keep the project plan updated with work that has occured and work that is ongoing. Planning ahead so that all 17 of us don’t run out of tasks is another nearly fulltime activity. I simply cannot imagine the effort it must take to manage the 200-300 or more people involved in EMHE each week.

My hat is off to the project planner behind the scenes at ABC who developed the template project plan, and to the onsite manager(s) who are able to utilize it to complete demolition of the existing structure and construction of a new house in 168 hours.

Filed under: Project Management

Project Estimating

One of the hardest aspects of any project is developing an
accurate estimate of effort and resources. There are really only three
variables that directly impact project delivery dates: feature scope, resource
availability, and time.

In my experience the scope is almost always set outside the sight of, or
control of, the design and development team. The client wants certain features
and is largely unwilling to barter on the set required for a successful
product. Granted the majority of my experience has been for government or
pseudo-government clients (e.g. Utility companies). While these clients aren’t
bottom-line driven, scope, and often time, are fixed variables in the equation
of project delivery.

At my current client the feature set required is immense (approximately 54 Use
Cases of effort) and the timeframe is rigidly set – 9 months. Using the
historical metrics available to us we have come up with an estimate of effort,
in person-months, of 255. Two-hundred and fifty-five person months of effort.
With team size the only variable we can adjust (i.e., time) we need 28 people
on the team to reach our goal.

 Just managing 28 people will require additional resources. Our
best guess is that project management and technical management each represent
about 10% of any successful project team. So our 28 person design team will
need three project  managers and three technical managers.

 If the client had unlimited funds, and if we could acquire a
total of 28 skilled resources, and if we could gather 5 or 6 dedicated
managers, and if we started today we could just make our date.

 In reality we have 8 people, 5 of whom need considerable mentoring
and who are not fully dedicated to the project. In short we are 20-24 people
short of meeting our goal.

Even if our team works double time for the next nine months, the equivelent of 16 people, we would still fall far short of delivery on time.

It’s going to be a long year.

Filed under: Project Management

Blind Man’s Bluff

The project I am on could easily be likened to one of the popular team challenges on Survivor. Frequently the two tribes are presented with a scattered set of puzzle pieces that must be collected and then assembled. The catch is that all but one team member is blindfolded, and the sighted team member must verbally guide his or her team to each piece and back to the collection point.

In my current engagement we, the consultants, are tasked with mentoring the client on using the Rational Unified Process (RUP) as the methodology for creating new applications. The push to adopt RUP came from the top down, so there are varying degrees of acceptance among the client resources on the various RUP-enabled teams. So far the work has consisted of heated discussions about concepts and language, with lengthy digressions into document formatting battles. In my case there is one team member who is fighting every new concept, every iteration over material, every bit of the new direction. It is massively frustrating.

Up until now we have had the charter to produce the analysis and design models for the application, and were expecting to be tasked with providing some form of post-design support to the implementation team(s). Yesterday we got word of a change in policy that is headed our way. The business management team is concerned that having the consultants lead the design effort while mentoring the employees won’t transfer enough practical knowledge to the employees. So the new direction that is being considered is consultants leading and participating in analysis activites only, while mentoring the client team through design.

Mentoring design?

Should this approach be adopted my days will consist of sitting in a chair behind the client resource telling them where to click, what to type, and how to complete the artifact at hand. Instead of doing the design with them, I’ll be reduced to an entirely hands off "blind man’s bluff" style of interaction. There is a challenge here, do I know the design techniques well enough to teach unwilling and poorly motivated resources? Can I find ways of motivating them to use new concepts and tools, when they disagree that there is a need for a new approach altogether?

And the largest challenge of all, can I motivate myself to stay here and relinquish an active part in the creation of the design? Or are my needs as a professional met only when I have an active part in the production of my assigned design goals?

Filed under: Project Management


Subject matter experts are a critical resource for any development effort. Without knowledgeable technical resources on your team during requirements analysis, analysis, and design it will be impossible to accurately and completely capture the essence of the desired application. All the modeling tools in the world can’t replace one SME.

In a consulting engagement, the SME role has a heightened significance. Resources who are experts in the methodology or tooling can be contracted for the project. But they cannot know the business at sufficient detail to move the project forward. The client must provide unfettered access to one or more SME resources in order to assure success.

My current engagement is frustrating as SME are constantly being pulled off the project to put out fires elsewhere. Repeated attempts to tie delivery date slippage to SME availability has had only limited success. In other words, we are still tasked with meeting our deadline even though we have just lost our SME for at least a quarter of the remaining project duration.

In true geek gallows humor the team has started to refer to itself as the “Kobiashi Maru” after the unsolvable command problem in “The Wrath of Kahn” from the Star Trek movie series.

Filed under: Project Management