image by Mike Pettigano, flickr artist

you hear the phrase a lot in football. coaches always want their players to run “north-to-south” when they get the ball in their hands. the ultimate goal, for any team, is putting the ball in the endzone — and running the most direct route that you can is going to get you there the fastest. the same can be said for running a project.

every project has an ultimate goal (at least they should); in order to get to that ultimate goal, there’s a critical path of key tasks you must complete in order to get to that goal. your project can be completed no shorter than the time it takes to complete this critical path. you’ll do yourself a lot of favors by considering this path to be your ‘north-to-south’.

there will be defenders along the way — difficult clients who want to add to the scope of your project, changes in leadership and vision, new features you develop that can be added — defenders that want to get you moving east-to-west.

ignore them.

when you set goals, you want to make them SMART:

• specific
• measurable
• attainable
• relevant
• time-bound*

example of a really bad goal: “lose weight this year.” first of all, losing weight is a stupid goal to begin with.  most people don’t realize that muscle weighs more than fat does, and working out might cause you to actually gain weight.  you should be looking for a better resolution.

example of a really good goal: “run in four 5k events for charity this year.” it’s specific, not just a random notion of weight loss.  it’s measurable because you can mark off events as the days pass through the year;  make it one run each quarter.  it’s certainly attainable.  asking yourself to run 4 marathons might not be, but a 5k is much more manageable and takes less time to train to.  it’s not an ‘always on’ kind of goal and allows yourself some wiggle room.  it’s relevant because your overall mission is to be healthier.  your soul will feel better too because you’re doing it all for charity.  and that asterisk i placed above is the most important for making goals… although i don’t necessarily see it in the same way as the textbooks do.  instead of time-bound i say to make that T in SMART stand for ‘tell everybody you know’.  telling other people puts that goal up-front and center.  you can’t hide from it because you just might have someone say to you in june, “hey, i thought you were running those 5k things.  what happened to that?”

so when it comes down to business, are you making SMART goals for your organization?  for yourself?  for your career?

it’s a new year, and there are no excuses.  come up with smart goals, write them down, and make sure you’re taking steps towards getting them every day.  start with something specific, measure your progress, make sure it’s feasible, ensure that it’s in keeping with your overall mission, and tell everybody about it.  you haven’t failed in the past because you weren’t good enough; it’s because you weren’t reaching for the right goals.

image by clagnut, flickr artist

project management can be described succinctly in two words: “be prepared to stop.”  [looks skyward...]

yes.

i’ve talked before about adding wiggle-room into your project schedules in order to handle setbacks, changes in scope, changes in requirements, and more.. this, however, is not that post.

no, this post talks about what to do when you run out of wiggle room.

you can only prevent bad things from happening to a certain extent, and wiggle room will only carry you so far.  some things are just entirely out of your control.  it could be something as ‘trivial’ as paperwork to get access to a system being held up, or as large as a massive power outage bringing down your servers for three days.  these kinds of risks are generally categorized as “known unknowns” or “unknown unknowns.”  some you know can happen, like a POC being out of the office on vacation unannounced, but you cannot predict when they might occur.  some, however, are entirely unthought of — like litigation being launched against your firm or organization which causes you to halt all progress.

when these types of situations hit, depending on your critical path, your progress can come to a complete stop.  you need to have a plan.  that plan should include some or all of the following:

include burn work

it’s good to keep certain tasks or kinds of work on the side as work that you can burn.  periodic reviews on work already performed, meetings to gather lessons learned to date, administrative work like gardening your team’s wiki or other collaborative spaces — these are all things that you can do that will both benefit the project by adding quality control, and keep you and your people busy.  when you can’t make progress on the project itself, there should still be some unscheduled work that you can burn.

take very good notes

perhaps you’re only on the first build of many on a system for a client.  you may be working on a program or providing a service that will be sold to a completely new client at the completion of the current project.  whatever the case may be, the most important thing you can do when work is halted is take notes.  look at what’s going on currently, and try to project similar situations out onto future projects.  learn from what you have encountered in order to create better plans for the future.

be transparent with your leadership

have a process in place where you can talk openly with your leadership about what problems are causing your progress to come to a screeching halt.  the temptation to lie about your progress to leadership is going to be amazingly high.  you don’t want to look bad to your peers… and you certainly don’t want leadership to think you’re incapable of effectively managing a project.  so you might think about saying, “we’ve hit a snag, but we’re still on track to meet our goals.”  you might think about hiding the “snag” altogether and just say, “our progress is around where we expected to be at this point in time.”  but don’t do these things!  be open and transparent with your leadership.  they might have the muscle you need to move those road blocks out of your way.

sometimes in project management, you can’t yield and be safe; it’s not enough to tap your brakes.  in some cases, you need to be prepared to stop.

image by elvez40, flickr artist

… they say you have to know where you’ve been.

i say, to get where you’re going — you have to know where you’re going.

stupid, right?  or is it?

whenever you start some sort of new venture, you have to know what the end state is. you have to set some sort of goal. otherwise, when do you know that you’ve gotten to where you want to be? when do you call it quits and move on to the next challenge?

i think one of the worst feelings in the world is when you’re churning away at something, tirelessly working, staying up night after night obsessing about how to perfect your work, and then one day asking yourself the question, where am i going with this?

some colleagues and i were talking about version control recently. in development terms, a product is usually given a dot-notation, integer-based version number.  v1.0 is generally identified as the first time you ‘go live’. this of course is not 100% solid; take, for instance, public betas and other test releases (you’ll also find RC — release candidate — versions in the wild). but what’s the difference between going from v1.0 to v1.1 — or — from v1.0 to v2.0? again speaking in generalities, a major change in functionality is usually denoted as a new version (i.e. v2.0) whereas enhancements to existing functionality or bug fixes are some form of dot-notation (i.e. v1.1 or v1.0.1).

but where does it end?

what’s the end state of your software, or your document, or your ms excel data model? do you stop at 3.0? at 4.0? at 4.0.23? beyond that? this is my point. when you talk about versions of something, it’s nice to say, “well we rolled out version 2.6 and we’ve started development on 2.7.”  it’s good for team morale. it certainly keeps the client happy (at least for a while) — but that doesn’t mean that you shouldn’t have an exit strategy. you ought to be building towards something; towards some kind of goal.

this is especially dangerous in agile or “spiral” development where requirements are made up on the go. “we’re done when we get everything into the system” is a horrible way to approach things. no one wants to be told that they could potentially be paying for something until the cows come home. there should be something that your system, document, etc. resembles in its finished state.  take that vision, make it your goal, and turn it into your mission.

what about your career?  what does sarah 2.0 look like?  for that matter, what does sarah 3.0 look like? when do you reach a new plateau and change direction to work on the next mountain?

to get where you’re going, you have to know where you’re going — otherwise, you’re just spinning your wheels.

image by Matheus Van Lobatos, flickr artist

as i see it (that sounds familiar [looks at blog title] oh yeah!…), there’s one rule of management which trumps them all. it’s what i like to call “the frank sinatra rule.” it’s very simple.  it says: “if you’re going to delegate, be sure that you delegate all the way.” many managers struggle with this key capability. people in power want to have all the power, but share the responsibility.

quite frank-ly (see what i did there?) — that situation is hardly ever going to work.

when you delegate, there has got to also be a delegation of authority as well as responsibility. if you don’t empower those folks underneath of you to make their own decisions, then you’ve only come half-way. not to mention, from a strictly business and financial perspective, you’re paying someone many thousands of dollars to be a “deputy project manager” or “functional lead” when you could have saved that money and gotten yourself an administrative professional or intern at a far lesser cost to handle things like scheduling meetings and organizing status reports.

the whole reason that you’ve appointed someone to a management role is because you are in some way overburdened. how do you lessen your burden without also lessening the amount of decisions that you need to make? the president of a corporation doesn’t make all the decisions. that’s why he or she appoints CEOs and CIOs and CFOs and CMOs and so on. why? because the president says, “i’ve got enough to think about without having such issues of ‘which web browsers do we allow our employees to install on their work machines?’ to deal with.” no work would ever get done if the president, chairman, or majority stock holder(s) had to make every single decision for the company. and there’s no reason that this dynamic should change in a project setting (with such a similar hierarchy of authority).

if you put people in charge of some kind of functional area but still wish to call the shots, what it’s really saying is that you don’t have trust in that person to make the proper decisions. and if you don’t have trust in the person/people whom you’ve appointed, what you’re really saying is that you don’t have trust in yourself, in your own ability to recognize talent and make good decisions about the people surrounding you. in either case — that you don’t wish to relinquish control, or that you don’t trust in your own people — it reflects rather poorly on you as someone who is confident and able to lead whatever project is at hand.

so when you delegate, don’t just put people in charge to handle administrative tasks and report back to you. when you delegate, be sure to pick the right people — then allow them to make their own choices.  when you delegate, follow the frank sinatra rule, and do it all the way.

photo by stress-relief, via flickr

in my experience, setting priorities doesn’t work.

ever.

why? for one simple reason: 98% of the time, the priority is set arbitrarily. “we need you to take care of this. karen says it’s urgent.” so should you stop what you’re doing and take care of what karen asked? it depends.

“is this task on the critical path?” — whether yes or no, this answer should be the primary metric for driving your efforts. often times a manager, or the client, or someone else who may not be involved in the finer aspects of a project will ask for you to do something that doesn’t reflect the core goals of the project. just because someone “wants” something doesn’t mean that it’s the right thing for them. the critical path is a map of current tasks and their interdependencies. if one task on the critical path slips, you’re now looking down the barrel of a loaded gun called schedule creep.

more after the jump.

when you start any project — and most certainly within the project’s life cycle, as requirements change — you should map out the tasks necessary to complete your stated objectives, and identify the critical path. many times you’ll find one key task that ends up being the driving force behind a vast majority of your work. this critical path will help keep you honest, and ensure that you’re completing that which should be completed rather than what you, or the client, wants completed. but the critical path isn’t the only metric you need to focus on; you also need to consider the level of effort involved.

you need to ask, “how much effort is this going to take?” when you boil it all down, you have 40 hours a week in which you can work. that’s 40 hours to get as much done as possible. if you have tasks that require a small amount of effort, why not pick the low-hanging fruit first? because in the end, it has to get done anyway — right? powerpoint decks don’t create themselves, and visual basic applications don’t troubleshoot themselves (though i long for the day!). if you look at effort, as well as the priority of the item, you can develop a matrix to show which tasks can be completed, and which cannot. it’s unrealistic to expect someone to complete a critically important task with a high level of effort and also find the time to complete a medium ranked task that also has a high level of effort involved.

it’s an unrealistic expectation because, as mentioned, your work week is limited. in fact — the man-hours on your project are probably limited as well! if a task falls outside of the matrix, you need to re-visit it and make sure that you’ve categorized it properly in terms of critical path, effort, and priority. however, if you’re certain that it was categorized correctly, then it’s time to bring the nasty pants out of the closet and tell the client their longed for bells and whistles won’t make it into the project — unless there’s extra funding (for more man hours, jelly doughnuts) or they wish to bump some other tasks from the current work load.

without having some sort of quantitative algorithm or qualitative methodology behind the labels, you risk finding yourself buried under a mountain of uncontrollable tasks and requirements.

so stop setting priorities; start thinking in terms of critical path and effort, and start working.

photo by mike_lockie, flickr artist

it’s going to happen.  no matter how much you plan ahead, or how much you think you might know — how comfortable you are in your abilities… you’re going to lose sight of your overall vision.

scope creep happens, and unfortunately it happens often. we all want to create amazing things, and we all want to deliver the very best we can to our clients. many times it’s the client who makes the changes! but either way, changes happen. instead of doing x, we do x and add on y because it makes x better in some way.

one of the most difficult things to do is telling ‘no’ to people who say, “you know what would be good?…” but there are times when it’s absolutely necessary. why? well no matter what you’re doing, you always have a main mission; every step you take along the way should be made to help you reach that end state. simply put, anything else is ancillary. so why do we always lose sight of where we’re going?!

because it’s fun to be creative! it’s awesome when you sit down, talking either among your internal team or with various members of the client’s organization and brainstorm new ideas (new ideas grow the business after all). we often get into situations when we have status updates and look at our progress only to find things that we want to change, areas for improvement. unknowingly, we tend to jump in without putting a toe in the water first.

in every project you do — maybe even every task — you have to set up points in time to have a reevaluation of your situation. ask yourself: “what am i supposed to be doing? what am i doing? does this get me closer to my end goal?” if you don’t set up these meetings or times for personal reflection, you’ll lose sight of what your original purpose was and find yourself slipping off track.

so set some time aside periodically to step back from what you’re doing; stop focusing on the trees, and find your forest.

photo by Balakov, flickr artist

i heard an interesting quote from a co-worker just recently. he said, “what gets measured gets done.” what’s more he said, “i learned that from a time management course that i showed up late for.” and he’s right! as they also say – “when the cat’s away, the mice will play.”

it’s nice to think that you can trust people to do what you expect them to do, but it’s hard for people to stay motivated when they know they’re not being watched. if a professor or teacher says they’re not going to grade homework, chances are that students won’t do it (or at least do it well).

it would be great if you could count on people without leaning on them, wouldn’t it?  now, let me ask you this question: how many people thought this post was about other people? now how many people thought this post was directed at YOU?

are you measuring yourself? what steps are you taking on a daily basis to make sure that you yourself are doing what you need to be doing?

in project management, we have metrics. you sometimes hear that word thrown about all willy-nilly to the point where people tend not to pay attention. people complain about keeping track of their time on a task-by-task basis, and PMs complain about having to keep their schedules up-to-date! why do all this?  metrics.

if you tell someone they should be doing a particular thing — coding time, entering data, tracking work completed — they might do it… for a while. most people will start off doing what you ask just because you asked. then, life happens. now what was once important to them suddenly becomes optional. but if you keep track of and measure it, people tend to give it a higher priority.

that’s why we have schedules and set deadlines, otherwise we’d have a difficult time getting anything done. we need metrics.  we need something that we can measure our efforts up to. am i on track? am i ahead of schedule? am i lagging behind the curve? this is the fundamental failure of many “to do” lists. people tend to put the task down, but not when it needs to be completed, or how many hours it will take to finish the job.

can’t get a handle on your inbox? set up a time every day (or maybe multiple times a day) to make sure that you answer every e-mail. even if you don’t have the answer, delegate! and get that e-mail out of your inbox. can’t find the time to get work done between all your meetings? set up a 2-3 hour long meeting with yourself to sit down and focus on what’s important.

sprinkle in some project management and time management into your own life. every day, make sure that you’re measuring up to what you need to do. make a plan and stick to it!

photo by Mr. Mark, flickr artist

human beings are predators.  that’s why our eyes are on the same plane facing forward.  it maximizes the area of overlap for the field of vision each of our eyes has.  this overlap allows us to perceive depth, and if you’ve ever worn an eye-patch for medical reasons (or you just happen to fully celebrate talk like a pirate day) — you have no doubt noticed how difficult it is to keep from bumping into things.

interesting information, but what does this have to do with business?  plain and simply put — you can only see what you can see.

some companies have project management offices (PMOs), others have processes, and many of the rest don’t have any.  so what do you use? basecamp? activCollab?  ms project? … none of the above?  the previous collection of tools all cost an additional fee for the full software package. because of that, you may be tempted to track your projects status in a word document, or a task list developed in ms excel.

the problem with that kind of approach is that you lose sight of a lot of great information that commercial software tracks for you. it’s not just enough to know what tasks you have open, or what projects are still under-way. you need to also be able to see who you have working those tasks or projects. you need to have the ability to see which tasks are affected another so that if schedules start to creep — and let me tell you, schedules WILL creep — you will be able to identify problem areas before they become serious issues.  so following are two free options that can help you keep better track of your projects.

the first tool is a gantt chart created in excel by antonio lupetti. his blog post includes a template that you can download and tailor for your uses. the advantage of using excel is that most people have it! chances are it’s included in your business’ office productivity suite of choice.  since it’s included, there’s no additional fee, and it’s widely available to your workforce. anyone can update and maintain a project schedule tracked in excel.

the second tool is another gantt chart template that you can use via google docs. and you’ll see if you use the template that the gantt char is actually pretty involved, and as long as you have a google account and your organization approves of putting company information on a shared web service such as google docs (or, if your organization utilizes google web services internally), then this template is one you might consider using as well.  it will show the tasks, duration, completion percentage, and allows you to include dependencies as well.

using either of the two tools mentioned, you’ll ensure that — no matter what you decide to go with in order to track your projects — you keep an eye out on the most important information involving your projects. so stop walking blindly, and don’t feel around in the dark looking for the thread to rope your projects back into line.  take off the blindfolds and open your eyes to the information you’ve been missing before.

image by tiago • ribeiro, flickr artist

when it comes to management, there’s a very simple principle that i feel makes a good leader a great leader:  for all the knowledge you might have — for all the skills and abilities you might have — it means very little if your team never sees you.

by definition, a leader is in front.  a leader doesn’t stay behind the scenes and control from afar.  that’s why when leading — a project, a team, an entire department — you have to be more than “the boss.”  it’s important to have the people who you rely on to get the work done see you.  it’s important to set aside face time to connect with your teammates and your colleagues.  it helps to show that you care about them and that their work doesn’t go unrecognized.

some leaders will post updates on a wiki, or through emails, or in project schedules and task lists.  but when all people see or hear are your words, it causes a disconnect between you and your message — be it positive or negative.  your admiration will be seen as obligatory and that you’re “just being nice because you have to.”  and your admonition will be seen as unjustified.  people will wonder, “how can someone criticize me and my work when they don’t even know me?”

in the same way that you’d expect your favorite NFL team’s quarterback to be talking with the receivers, running backs, and offensive line on the sidelines, you have to be talking to your own team as well.  from the skilled positions, to the ones who do the ‘grunt work’ — you have to be working as hard at communicating as the quarterback because… well, you are the quarterback.

when you speak through email and other forms of written text, it’s easy to lose context.  don’t just let your words speak for you.  be visible and let you speak for yourself.