1. Knowing the codebase - Since my hands are in the code and I am seeing/understanding its progression, I know exactly the state of the project at all times. I know where we need to allocate more resources to fast-track a task. I know where the critical paths are and how we’re handling them day-to-day. I can give an update on where things are at at any moment. I can answer client’s technical questions or get ours answered without wasting my key developer’s time.
2. Peer respect - Since I am not supervising from some “lofty, exalted, I’m-the-dude-in-charge” sort of way, but am actually helping the effort, I gain more respect from the team as only a peer can. One of the greatest compliments I’ve ever received was the anonymous employee/peer review feedback which stated “I wish we had two of Andy: one to do frontend development full time and one to manage full time.”
3. Staying frosty - By continuing to develop and staying current on new technology I am better equipped to come up with technology solutions for clients. Managers who are more distant from technology are, I think, severely limited in their ability to find creative and innovative solutions since their perspective of what is possible comes through the lens of a laymen.

There is also one other added benefit that has more to do with personal risk management. My uncle (a long-time government worker/programmer) said one of the greatest dangers for developers going into management is for them losing their coding skills. Since in technology company managers tend to be “home-grown” or raised up from the existing body of employees rather than brought-in, when companies go under managers who got their start in development are often forced to go back to coding when seeking new employment. Keeping our development skills sharp so that we will always be competitive in the most currently sought-after positions means we’ll always have employment options. This peace-of-mind alone is worth the 5-10 hours a week I spend in actual development.

Before diving in I do think one point is worth making as a disclaimer. There are some important differences between PMing at an agency doing client work and PMing internal products/projects. Namely, when you’re a PM over internal projects sometimes business requs are vauge, but the budget and timelines are fixed. That’s a challenge I don’t envy and which, fortunately, we rarely deal with.

What are the specific steps you take for resources estimates on tasks?

1. Ensure we have enough information from the project sponsor. Ask the questions they haven’t thought of. Conduct initial risk analysis and run it by the sponsor.
2. Run all assumptions I make as PM past the project sponsor prior to estimating.
3. Create a task list.
4. Do my best to have the resources doing the work doing the estimations.
5. Ensure the project requirements are understood by resource.
6. Request resource to account for any tasks I may have missed and add them to task list.
7. Compile all resource estimates and “high-level” it (check it against other projects of similar scope and size and make sure nothing seems “off”).
8. Conduct formal and informal reviews with resources during and after the project for critique of estimations.

Do you have standard methodology for document estimate, actual variance?

I do use a common document we’ve created at Rain which lists tasks common to most projects which serves as a start to task lists. This document also contains a worksheet for estimating resources and skillsets required for a project necessary for resource allocation and planning.

How do you estimate resources required for tasks that you don’t have experience with?

If neither I nor personnel on staff have any experience with a needed task we do as much due-diligence as is feasible without budget (usually a few hours to a day or so depending on the project size). With our research we make an informed estimate and then simply double it.

Do you classify previous tasks and use them as references for estimating new tasks?

Absolutely. It would be sheer idiocy to do otherwise. Whether a project is hourly or not, resources are required to track their hours to the nearest half hour to specific tasks in our project management system. When we bid on projects which are similar in scope and business requirements we use these archives to inform our bid.

How do you account for padding? Managerial or individual? Do you oppose padding?

I would oppose padding more if we were having difficulty winning bids. Honestly whether or not I pad depends on how badly we need work at the time. When we have as many projects as we can handle padding on fixed-bid proposals allows us to mitigate our risk.

In general I will always pad if I or resources helping me with estimations have either never done work similar or seem unsure about their estimates. I like to be there with the resources when they are making bids and watch their body language. If they struggle or hesitate with an estimate I want to manage our risk by providing some padding above and beyond what they have provided. When resources are sketchy on estimates they almost always under-bid. On the other hand, when resources are confident with an estimate I trust them.

Another important thing which many consider “padding” but which I do not is accounting for discovery, account management, and quality assurance tasks. I subscribe to the rule of thirds when it comes to software development (with some varience depending on the type of project). 1/3d goes to discovery, design, and prototyping. 1/3d goes to development. 1/3d goes to iteration and QA.

How do you manage resource estimates when you believe they are padding their numbers?

I am very honest with resources and work closely with them in creating project bids. I ask them not to pad but to trust their instincts. I try to have them go with how long a task “feels”. Again, by watching them react to the listed and described task as they think it through I can gauge whether I need to pad their estimate or trust their confidence level. This depends, certainly, on knowing the employee well and having mutual trust which is important for project management anyway.

How do you account for a learning curve? for new technology? for new employees?

I think I covered learning curve and new technology above. Our newer employees often do not have experience providing detailed estimates and being accountable for those estimates throughout a project. I try to get them engaged in the estimation process as soon as possible so they can become skilled at it. An important part of this is helping them to go back and review days, weeks, and even month’s worth of effort from their reports so they can learn how long they take on specific tasks.

But I do not rely on new employees for actual bids if I can avoid it. I will still have them bid, but also with a more experienced employee bidding as well. Of course, it’s important to take into consideration difference in speed and skillset with newer resources vs older, more experienced resources. I will then have them compare bids and talk about and justify their estimates. I find this exercise very helpful.

How do you account for differences in employee productivity?

Differences in employee productivity is less important than work accomplished vs work estimated. Since the goal is to have the resource who will be doing the work being the one who does the estimations, the point is often moot. Gauging and learning from differences between estimates and performance is huge. But managing productivity is another blog post entirely.

How do you handle vague requirements?

If requirements must be vauge (as they often are) I do one of three things, depending on the preference of the project sponsor:

1. Pad the hell out of it so the risk on my end is managed. I want me and the team to feel confident that our numbers are so high that it will never come back to bite us.
2. Take our best and most realistic guess of what the effort will be and procure budget for 1/4th of it. That 4th will pay for the discovery and prototyping. When discovery and prototyping are complete and the sponsor and stakeholders are all happy and have signed-off, we then provide an accurate fixed bid for the remainder of the project.
3. Do the whole thing hourly. There are many tasks I refuse to take-on at a fixed bid. One of these is system-to-system integration when working with a 3rd party that has no well-documented API. We do these tasks hourly every time.

Have you had success with task estimation?

Absolutely. Since adopting this “philosophy” (which is a dynamic and not a static thing) my projects have rarely been over-budget or timeline unless there has been significant changes. Even in those cases, between either our prototyping process (my second approach to vague requirements above) and change orders, we don’t get burned by scope creep much anymore.

Do you make specific estimates or range estimates?

A client or sponsor will always hear the lowest number. I don’t provide ranges. If I have to I provide “~” in front of one number when providing a gut “range” or “scare-away” price. I want to emphasize the importance of this “scare-away” price in agency work. Often too much time is wasted with potential clients in due-diligence when what you thought was a project in the hundreds of thousands and they thought was in the thousands. A lot of time can be saved by throwing out a “gut” number first. But yeah, I hate ranges.

How often throughout the project do you review/update estimates?

Depending on which way we are doing a project (fixed, hourly, prototyped) the answer is different. If we are doing hourly (usually with a retainer agreement) client’s demand rigorous attention to reporting and so it a monthly task of reviewing and updating estimates. With prototyping there is a formal review/update at the conclusion of the discovery phase. With fixed-bids reviews are less formal. Usually they come up when a change-order is required (which is fairly common).

In other words, when I tweeted tonight “Trying to fall asleep with a little help from Tchaikovsky” it wasn’t because I honestly thought the whole world needed to know or cared about my sleeping habits. It was because I know that there are some people who love and appreciate me who are going to be interested in knowing that I have been having a resurgence of insomnia lately and that I love Tchaikovsky. This equates to idol conversation. There is both an un-spoken question and an (often) unheard response. But it is a conversation. And common, idol conversation is the glue that binds relationships that have any value. This is why I wish more of the people I cared about used Twitter and why I think the afore-mentioned arguments miss the point entirely.

<soapbox />

I think our discovery/prototyping process is something that sets us apart from not only other digital agencies, but also traditional software development agencies. Over the last ten years we’ve spent a lot of time perfecting our process with the single most important goal of making superior interactive experiences that we and our clients are proud and that users love.

The process, as we have it now, helps us dial in client and user needs prior to wasted development efforts. We’ve learned that clients and users never truly know what they want/need in a vacuum. It’s easy to make lists and requirements but, unequivocally, they will change during development and user feedback. If those changes come after scope has been locked down or formal development has begun it leads to three problems:

• Change management can easily put the agency and the client at odds, which is the worst thing for developing a superior user experience. As a producer, I want more than anything to worry about how to make the app the best it can possibly be for the client and user. I can’t do that as effectively if I need to constantly balance change-management against a fixed bid (scope creep). We need the flexibility during discovery to question everyone’s assumptions before we arrive at the best solution.
• The codebase infrastructure can be severely weakened if important features or user experience changes are introduced late or even early in the development and architecture process.  This makes the cost/time of maintenance and debugging go up by by multipliers since extensive refactors were never in the original roadmap and architecture.
• With traditional methods the client does not get to see the finished product until it’s just about done. They may have seen some wireframes or comps, but final functionally is often what the developer has done is what they get. And while this will usually meet all of the scope requirements, requirements and implementation are completely different matters and the client is often very dissatisfied with the final outcome.

To avoid these issues we put a high priority thorough prototyping. Here is our process:

• Proposal: Business requirements / experience objective
• Prototyping phase
• Usability and prototype iteration
• Project requirements document and adjusted statement of work
• Development
• QA
• Deployment

Proposal: Business requirements / experience objective

These phases should be fairly self-explanitory, but the one I want to emphasize and discuss the first three. We first spend a lot of time getting to know the client’s desires and business model for the experience. We also spend a lot of time trying to understand the demographic and users’ needs. With the client we will then develop a proposal including our current understanding of objectives and business requirements. This will only serve as a guide as well as what we will use to come up with an estimate.

Prototyping phase

Once we have the estimate we charge the client a fourth of it to begin the prototyping phase. This phase starts with further definitions of business requirements, user persona development, and other preliminary documents that will guide the whole process. As soon as possible we’ll start throwing features down in wireframes and developing use-cases. At the same time we have creatives working toward branding objectives that will be merged with the wireframes once they both near finalization and approval.

Usability and prototype iteration

The end result of the prototyping phase (most of the time) is a functional, smoke-and-mirrors, prototype that give provides a real experience with as many as the main use-case flows as possible. We can use this with the client to make sure it meets their objectives and is exactly what they want. We also use it with users in formal usability studies. At this point it’s easy and cheap to question assumptions by adding or changing features and we welcome this. This is imperative to make sure the experience is the best possible before we’re locked into development.

Project requirements document and adjusted statement of work

When we have sign-off from stakeholders on the prototyping and accompanying documentation we feel good about beginning development. We also are then able to dial-in the cost of development accurately whether up or down based on inevitable changes.

Development, QA, Deployment

The point of the above verbiage is to show the imortance of solid prototyping. Once that is done effectively, the development, QA, and deployment process can follow any number of agile methodologies with similar or varying effectiveness and outcome. But delving into these is not in the scope of this discussion.

While working as a frontend web developer managing FranklinCovey’s Symposium website I was amazed at the sheer amount of copy edits I was asked to make and which were often as simple as “can you change the n-dash in the third paragraph to an m-dash”. Even though the tasks were small and with many of them I was tempted to stick it on my todo and deal with it when I was done with “more important tasks”, I made it a point to make each change when I first read the email requesting the change. The client was so impressed with this they emailed the president of my company requesting I be sainted. I remember how much this meant to me at the time. Certainly verbal rewards, when they are heartfelt and warranted, can do much to create an effective and loyal employee.

But one thing managers must be careful of, that wasn’t explicitly mentioned in the BNET article, is to avoid condescension. This is particularly true when leading teams of programmers. If there’s anything I’ve learned about the programmer’s mind, it cares little for elegant decorations and hype designed to change the appeal of something. Managers who use carefully developed “motivational” techniques on software developers, designed to increase performance or augment loyalty, will often find it backfiring. Developers have the excellent ability to see right through pretty speeches and get to the heart of an idea. In other words, praises, motivational speeches, complements etc, if they are not heartfelt and presented with logical evidence of their merit, will likely produce the opposite of the desired result.

I want to particularly emphasize the logical evidence of merit. I think at the heart of condescending praise is the insufficient merits regarding the action. This might work with a child or for someone with low IQ and desperate for attention (“Look how much your handwriting has improved!”) but most people, and especially an analytic mind, will recognize the degree to which the compliment was been warranted.

It’s happened to all of us at some point. We’ve received an email like this:

Now emails like this can be timely and helpful. Sometimes we just need important info fast and we don’t care the form it comes. But then the wheels of time turn…

Soon the email becomes an obscure blip amongst the thousands and is no longer viewable among the most recent ten. We find ourselves needing to refer back to it, but it’s too buried to browse for. So instead we do a search. Since the sender didn’t mention the nature of the information, just something lame like: “Ok here it is! LOLZ!” we don’t find it by subject. Next we search by client. Since the original sender didn’t mention who they represent, we also find nothing. So we search by sender but again, since the email was forwarded from someone else on our team… nothing. Now, the point of this article may have become apparent to you, but before show my hand entirely, I want to bring in an important lesson from SEO.

Keyword/Keyphrase Optimization in SEO

Anyone who knows something about SEO will tell you that one of the most important things you can do to get content in front of eyes is to figure out who you want viewing it, figure out what phrases they might use in a search engine to discover it, and then make sure those phrases appear in your content. This most basic SEO principle will increase the likelihood that users you want seeing your page will see it. This technique is called keyword or keyphrase optimization and those who ignore it do so either because they are ignorant of its advantages or, due to virility or fame (like if Sarah Palin started an NRA watchdog blog) they just don’t need to.

ESO

I’d like to borrow this principle and submit that everyone, regardless of our line of work, regardless of how often and in what manner we email, should make use of it. And I’d like to title this principle, email search optimization or ESO*.

* An Andy-licious acronym which is sure to become widely adopted

ESO is all about manners. It’s about respect and having good email etiquette. It’s about making establishing habits of communication that are going to help our loved ones, coworkers, clients, and congressmen have better access to information. After all, a huge part of success in our day is all about having the right kind of access to the right kind of information at the right time.

ESO is pretty simple. It includes the following principles:

Informative Subject Lines

Instead of “Ok, here it is! LOLZ!” we might write “Information about x for client y” so that a search about the information’s topic or the client’s name will yield results.

Descriptive Message Body

Don’t use generalities in the message body. Instead of “that thing I told you I’d get to you” you might write “This is x document that addresses problem y”. Again, this helps give context to emails that will no doubt later be quickly glanced over to find specific information.

Don’t Email Thread Hijack

A personal pet peeve of mine and among the top ten all time most annoying email practices ever invented… Well… Here’s the example:

You get the idea. When starting a completely new email thread regarding an independent topic, it’s best for the sanity of those who live and die by email to start a new topic. I have been absolutely amazed at the number of professionals in the business world who feel that their time is so valuable that it’s best if they find an email by the person they need to email and simply reply to it, giving little or no regard to the subject of that email. This can be even worse than the first example for finding information since information is then deceivingly buried in a misleading email thread topic and initial discussion chain. This is, effectively, the witness protection program for information. And when it happens to me I end it fast by “replying” to the email with a new subject line. Which actually should be another principle…

End Email Thread Hijacking by Replying With an Appropriate Subject Lines

See above.

Conclusion

Whether or not the world accepts ESO as a new web meme, lets all do our part to make the land of email a better and safer place for us… nay! For the children!

Some managers think the answer to everything is to squeeze as much effort as possible out of developers. Asking them to pull crazy hours only gets you so far and quite often is only a temporary solution. As an alternative, all of the following can be used as a first step in attempting to meet crazy deadlines:

• Ensuring business requirements are crystal clear
• Providing the right tools (software/hardware/code libraries)
• Access to development libraries and code bases before they need to ask for them
• Immediate answers to questions they may ask and getting these answers before they have to ask wherever possible
• Making lunch runs
• Keeping meetings short and relevant
• Keeping developers a step or two removed from politics or drama that may come up with managing the client
• In general making sure developers are enjoying what they are doing to the greatest extent possible

One of the hardest aspects of this is knowing what everyone is working on and knowing exactly what is next for each person. Nothing kills efficiency like resources sitting on their hands waiting for answers, designs, or for a project manager to get organized.

When timelines get tough is when the project manager needs to be their smartest. It’s easy to cop out and demand overtime. That should be the last resort. The first response should be to get ducks in a row.

Waterfall

1. Define project scope and timeline.
2. Allocate budget, resources, and milestones.
3. Do your best to keep the project on track in spite of numerous important additions to deliverables and business requirements that could never that could never have been predicted and accounted for in a vacuum (during due-diligence).
4. If you’re lucky, have amazing resources who don’t mind working gobs of overtime, and are able to keep change orders to a minimum, you may deliver the product on time, but often to the dissatisfaction of the sponsor and/or user who had to wait until the end of the project to discover that their vision for the project wasn’t quite what yours was.
5. Oh yeah, and you couldn’t QA because that was the first thing to go when the project started to get behind. You end up calling it “beta” and fix things in production.

Agile

1. Define business requirements.
2. Divide business requirements into categories of “vital”, “important”, and “would-be-nice-to-haves”.
3. Estimate resource and budget requirement for a first iteration that includes vital features.
4. Allocate a portion of those resources and budget to the creation of a functional prototype (or wireframe walkthrough depending on the project’s complexity).
5. Iterate upon the prototype and project requirements document (including use-cases) until project sponsor and users (usability studies) sign-off and the resulting feature-set falls within acceptable timeline and budgetary parameters.
6. Develop test plans that follow use-cases defined in discovery phase.
7. Development cycle begins with iterative sprints toward important project milestones.
8. Each sprint includes QA and unit testing.
9. Usability studies are conducted at appropriately defined milestones.
10. Version 1 is put into production and step 3 – 9 are repeated for the secondary or “important” features.

To understand how he arrived at this conclusion it is important to understand the agency he is representing. Rain is a digital agency specializing in rich internet applications. If we are able to sell our services it’s because we are able to somehow able to convince a potential client that we can increase their revenue in one of three ways:

1. Create a rich, interactive, marketing experience that generates leads/sales.
2. Create a rich internet application which allows them to sell a particular product, service, or some sort of digital content.
3. Create a rich application which has the potential of improving internal efficiency, thereby decreasing operation costs.

Knowing well that his purpose was to help identify ways in which we can step in and find solutions uaing any of the above approaches, he realized that most of his leads and sales efforts had been directed at non-technical marketing folks who rely primarily on traditional methods of marketing and who possessed a weak knowledge of the potential of interactive approaches. This lead him to two conclusions: First, if he was going to be successful at finding ways to sell our services to these folks he was going to have to do a better job at being a tech evangalist (he needed to do some education before he could ever land a deal). Second, he needed to expand his efforts to include CTOs or CIOs or other decision makers acquainted with technology and who are more apt to accept the possibilities of our unique experience and solutions.

But there was also another thing that presented a challenge. While this new employee is excellent at networking and sales, his ability to both teach non-technical folks or to communicate with tech-savvy decision-makers was limitted. He realized that he was going to have to sharpen his knowledge of the potential of the web technologies we specialize in.

In an effort to point him in the right direction, I sat down and gave him a quick list of some things he would need to be familiar with (at least on a high level) if he was going to be able communicate in a language that would make sense to tech-savvy decision makers or to educate and sell to the rest. I thought it was a list worth sharing to others who may find themselves in a similar position. This list could also serve as a point of departure for producers, project managers, presidents etc who want to expand their leadership potential into the digital/interactive arena.

There’s a lot to learn and this is by no means an exhaustive checklist. But having a basic understanding of the following will get you a long way:

Programming Principles

• Procedural programming
• Object oriented programming
• Scripting
• Database management and normalization
• Languages vs frameworks
• Scalability
• Memory management
• Cloud computing
• Web hosting/management
• Desktop, web, and mobile development techniques and technologies

Development Cycle (in no particular order)

• Agile vs waterfall
• Business requirements
• Iterations/sprints
• Milestones
• Code complete
• Quality Assurance
• Usability testing
• Unit testing
• Wireframe
• Prototype
• UX
• Information architecture

Potential Team Roles (likely overlaps)

• Backend/server-side development
• Frontend development
• Database management
• Design team
• UX
• Information architect
• Content writer
• QA
• Sponsors
• Stakeholders
• PM/Producer

Important Languages and How They Are Best Used

• HTML/CSS
• JavaScript
• Flash/Flex/Air
• Silverlight
• Java
• Objective C
• C#
• ASP.NET
• PHP
• Ruby
• Python

Major Server Environments and When They Are Best Used

• IIS
• Apache
• Tomcat

Major Database Technologies and When They Are Best Used

• MySQL
• Sequel
• Oracle