Help Wanted: Someone who has failed

“The only real mistake is the one from which we learn nothing.”

[Henry Ford]

Failure:

Everyone eventually fails at something.  Most of our failures are minor like getting behind on an assignment or telling a joke that no one laughs at.  We stress out a little bit, then move on.  For some, moving on means working hard to fix the problem.  Others accept their role in the failure, but also accept the results.  And there are some still who revert to a 12 year old mentality and attempt to blame everyone but themselves and could really care less about the results.

Many people will go through life never experiencing a spectacular failure.  In other words, the failures they encounter will generally be isolated to a day or two of discomfort that is quickly forgotten.  There is nothing wrong with this per se.  Some roles in life just aren't that exciting or complicated.  Large scale engineering does not fall into that category.

One of the interesting experiences I have had the privilege of being a part of was an education at the US Naval Academy.  The entire freshman year (aka Plebe year) is designed to make most people fail.  This isn't just another check box of intentional hazing.  Rather, it is explicitly placing a group of young men and women who have largely been successful in academics or other endeavors into a position where success is almost unreachable.  A few extraordinarily talented ones pull it off.  But the rest of us had to learn time management, prioritization, and most importantly accountability for the tasks we simply could not achieve.  We all walked away from that year knowing how to deal with adversity.  Knowing the agonizing pain of pushing ourselves to the limit and still falling short.  And above all, knowing how to pick ourselves up off the ground bruised and battered and press on to the next challenge.

Help Wanted:

This is why when I interview people, I try to drag out of them a story from their past where they have failed spectacularly.  Amazingly, this is either difficult to find, or folks feel embarrassed to admit it.  There is nothing wrong with failing.  There are countless pioneers of the past who celebrate failure as nothing more than a learning point.  When asked about his many attempts to get the light bulb right, Thomas Edison famously said "I have not failed. I've just found 10,000 ways that won't work."  The ability to deal with and recover from adversity is an enormously valuable skill that should be highlighted on any resume.  Demonstrate that you can push to the edge and learn from your mistakes.  Show that when the going gets tough you don't fall apart under the pressure.  Show that when you fall short, you are able to accept your role and seek self improvement.

Everything big I have ever done has been consistently understaffed or placed under timelines that are unreasonable at best.  Eight hour days are a rare occurrence and lunch is something that gets inhaled while walking from one meeting to the next or sitting at your desk.  Education background is a check box and skills are negotiable.  Learning on the job is par for the course on big projects.  I have time to teach someone how to write Interface Control Documents or Test Plans.  I don't have time to discover they are going to fall apart when things don't go as planned.

I need engineers who have had it rough.  I need a team who has left it all out on the field with nothing more to show than a plan to do it better next time.  I needs folks who have failed spectacularly while seeking greatness and lived to try it again.

...and I'm hiring right now...

http://jobs.meetngc.com/brooklyn-jobs

Back in the saddle

“So what do we do? Anything. Something. So long as we just don't sit there. If we screw it up, start over. Try something else. If we wait until we've satisfied all the uncertainties, it may be too late." 

[Lee Iacocca]

The Big Apple:

On April 23rd, I boarded a flight from Los Angeles literally leaving a job site from FATPOT Technologies to report to a brand new position with Northrop Grumman in Brooklyn.  There is very little in common between my life now and what I came from.  With FATPOT, I was living in a relatively rural beach town and travelling on a schedule that could be called erratic or even borderline insane.  Now, I find myself in a polar opposite world of the biggest city in the US and rarely even driving a car, much less flying somewhere.  I have to say that I feel more at home in the big city.  There is never a shortage of things to see and do.  Any possible kind of food or entertainment is usually just a few train stops away.  Having a more predictable schedule combined with being more physically active has made a huge difference.  I've already lost 21lbs and will likely lose 20 to 30 more by Christmas.  My family is currently down in Brazil visiting relatives, so I've had the freedom to really explore the city.  I particularly enjoy walking around Times Square.  The people watching alone is worth it, but the geek side is also fed with some pretty impressive technology on display.

The Big Job:

Part of why I haven't kept the blog up recently is my new job.  For the past 9 years, New York city has been trying to completely overhaul its Emergency Communications infrastructure.  They started with 9-1-1 services being spread across the five boroughs of Manhattan, Brooklyn, Long Island, Queens, and the Bronx.  EMS, Fire, and Police all used antiquated systems that didn't talk and had their own share of autonomy that would be challenged by coming together.  The intent was to consolidate everything and upgrade many of the systems to cutting edge technology.  Originally, Hewlett Packard was brought on to manage the project.  I'll avoid the easy target of questioning what the expected result of a consumer commodity company being in charge of a giant government project involving high levels of customization.  The bottom line is that Phase one of the project did not go well and had huge schedule and budget overruns.  In mild defense of HP, some of that was at the direction of the customer...but not all of it.  As the project gained more and more negative press, the city created its own management office to provide better supervision and called it the Office of Citywide Emergency Communication.  They replaced their previous independent oversight mechanism with NASA's Independent Verification & Validation office (yes, the space guys). Finally, they hired Northrop Grumman to serve as the System Integrator for the second phase of the program.

I have come on board as the Integration Manager with the principle goal of providing coordination, oversight, and final system integration and verification to all the individual projects that are bringing together New York's  brand new 9-1-1 facility currently being constructed in the Bronx.  Radio expansion, Network harmonization, Computer Aided Dispatch software replacement, Telecommunication Infrastructure build out, and over 50 different software interfaces to a host of other Public Safety related systems cross my radar every day.  My challenge is to coordinate the dance that everyone must make in 2015 to ensure that every subsystem is correctly installed into the new facility, interconnected, and thoroughly tested to ensure that the first 9-1-1 call taken is executed flawlessly.  There are occasional moments where I question my sanity on taking this on.  Bust most days are head down through long hours enjoying the excitement of this challenge.  System Integration is what Northrop Grumman does for a living and it has been my background now for well over a decade.  I get to work each day with a great team of professionals and am learning from them all at the cyclic rate (Marine jargon for as fast as possible).

The Big Geek:

The past three months have had some huge adjustments.  Diet and exercise have been a major improvement.  I'm thoroughly enjoying the big city crowds and excitement.  I spent almost two months with no furniture.  And now I am on my second month of running my entire personal life on Linux.  These are all some of the other factors on why I neglected the blog.  I've finally reached a level of comfort to get back into full research mode.  I have to say the addition of air conditioning to the apartment yesterday is probably the biggest one though.  It's a bit tough to stay at the computer when your office feels like a sauna.  

Linux adaption has been the big fight.  Nearly two decades of always having a Windows machine available made me take some basic stuff for granted.  Having to manually install drivers to watch DVDs or manually set the resolution on my second monitor have been the minor ones.  Getting FitBit to work and opening my old Outlook .PST file have been major challenges that I have not really had solid victory on.  FitBit simply has no support for Linux (unless you count Android) and I am stuck running Windows 7 in an Oracle VirtualBox until I get a new phone that supports Blue Tooth 4 devices.  The .PST file has been even worse.  I tried doing an import through Evolution and through readpst.  After 36 hours of Linux actually bogging down so badly that it wouldn't respond, I had to kill the effort because I had more important things to do.  Only about 60% to 70% of the mail got imported.  The 9.3GB mail archive opened in seconds on my Windows machine at work.  I may just have to look at the code on these projects to see if there isn't a more graceful and user friendly way to deal with large mail archives.  

The Big TPM:

The great part about Northrop is that they really invest in their employees.  I have access to an internal library of interactive training, the full Skillsoft library, and the program itself does regular internal training on basic project management process.  I am looking forward to doing some writing about the importance of good requirements and test procedures that only a PM Geek could enjoy.  More to come...

A Message To Garcia

"Anything such a man asks will be granted; his kind is so rare that no employer can afford to let him go. He is wanted in every city, town, and village - in every office, shop, store and factory. The world cries out for such; he is needed, and needed badly—the man who can carry a message to Garcia."

[Elbert Hubbard - 1899]

Motivation:

At least once a year, I have some staple things I go back to that get the adrenaline flowing.  I think everyone finds these things in their life.  Whether it be movie, song, book, place, friend, or other; we all have something that reminds us why we love doing the things we do in life.  As an Engineer and Technical Project Manager (TPM), my things are tied to making the impossible happen.  Along with watching Apollo 13, Elbert Hubbard's "A Message to Garcia" is one of my favorites.  I'm sure some past co-workers already rolled their eyes when they saw the title of this post.

I have made many people read this story through the years.  Anyone who has ever been tasked with managing people knows the acute frustration faced when a team member requires "baby sitting".  Very few TPMs are blessed with a project where all they have to do is assign tasks and track progress.  Most TPMs are hired for the position because they also possess the relevant skills and background to step in and get work done along with the rest of the team.  No one wants to schedule slack to deal with "slower" employees, but we have all had to do it.

Read A Message to Garcia

The Point:

Before past co-workers get too worked up, I am not claiming to be "Rowan".  We all have bad days, moments of weakness, and occasionally legitimate reasons to push back on a task.  The story comes across as pretty negative towards employees in general and implies a level of military obedience should be observed in the civilian world.  Don't let that distract you from the core message.  If you didn't click the link above, please do so now.  The story is only a few pages.  The point of this post is to talk about what the "Message to Garcia" means in today's world and why I will continue making people read this for the rest of my life.

First let's make some basic observations.  The task given to Rowan was pretty basic in the realm of scope.  As an officer in the military, Rowan would already know who Garcia was and where he was at.  I would compare the discovery portion of this to being tasked by the CEO to ship a large item to a remote office in a 3rd world country.  You still need to figure out exactly where the office is and what avenues are available to get stuff over there.  In war, haste on anything the President asks you to do is implied. I would argue the CEO has that same level of gravity in business.  So there really is nothing else you need to ask him.

What makes this comparison slightly off is we have so many things available to us today as information tools. Even the laziest of employees can tap a few words into Google and figure out most of the steps on executing this task.  But now ask yourself, how many people do you actually know that would pull this off in a timely manner if the internet went down?  How many people would pick up the phone and start calling FedEx and corporate HQ to start asking questions?  If you had VOIP phone service that was also down, how many people would get out of their cube and drive to FedEx or HQ?  We all know the answer to those questions is not many.  We've all seen progress screech to a halt when the power goes out, or when a certain tool is offline for maintenance.

The sad part is that we also know people who wouldn't pull this off even if they had every resource available to them.  Never mind that they are smart enough.  Never mind that you don't have anything else important tasked to them.  They will just sit in their cube staring blankly at the monitor wondering why this wasn't assigned to someone else.  They may make a single query in Google or a single call to FedEx and then give up when they don't find the answer right away.  They will never carry the message to Garcia.

Real Problems:

TPM tasks are rarely as simple in scope as the task Rowan had.  But they are also rarely as difficult in lack of support or presence of danger.  Whether it's fixing a bug, building a new feature, or taking over someone else's project, the process is always the same:

• Identify needed skills
• Identify needed supplies
• Identify key stakeholders
• Get approval for skills and supplies with stakeholders
• Build your plan based on what you are given
• Win!

Today we have Google and Amazon.  There is basically no skill required in the technical world today that you can't teach yourself with proper tradeoff of sleep and caffeine.  And sourcing supplies is faster and cheaper than it has ever been in the history of history.  The only thing that keeps anyone from succeeding today is themselves.

But that's impossible!:

I'm not going to dwell on this much.  Yes, sometimes the task that comes down is factually impossible.  99.999% of the time that word is thrown out prematurely.  Don't let yourself get set up to fail.  If scope needs to be addressed, then address it.  Use your risk register for what it is for.  But treat the word "impossible" like the most foul word on the planet and only use it when you know beyond all doubt that there is no other option.

As a freshman at the US Naval Academy, you are only allowed to give five responses to a superior:

1. Yes Sir
2. No Sir
3. Aye Aye Sir (means I'll do what you just told me to do)
4. I'll find out Sir
5. No excuse Sir

There is something to be said about trying to approach your job with that limited vocabulary.  No excuses, no giving up, no deflecting blame.  Whether you agree with everything in the story or even my take on it, I've never met anyone who didn't desire to work with someone who just gets stuff done, no matter what.

Why this rant?:

As I said above, I'm not claiming to be perfect.  I'm not always just like Rowan, but I strive to be.  This week I am starting a new job with Northrop Grumman.  I am the TPM responsible for moving all of the systems that support New York City's 9-1-1 Response to a new facility.  This has never been done before.  There is no instruction manual.  No senior employee to show me how.  And there is zero margin for failure.  But I've been preparing nonetheless.  I've been getting myself motivated.  And I am ready to take the message to Garcia!

Geek Update for March

"Do not wait to strike till the iron is hot; but make it hot by striking."
--[William B.Sprague]

Recap:

The month of March has been a roller coaster of action and emotion.  This Blog is just one piece of the puzzle in my decision to re-invent myself and focus on becoming a better person in general.  Being a Geek is who I am and drives the core of all of this.  However, March turned into way more than just dusting off the old C++ compiler.  One of the major decisions last month was to leave my current job.  It has been an adventure to say the least and a very rewarding experience.  I do regret leaving all the great folks at Ci/FATPOT behind, but it is simply the right thing to do for my family, career, and I believe even for the company as well.

The Geek side of things stayed pretty active.  ASP.NET and C# are up and running which may work well for a potential opportunity in Afghanistan.  I also stood up three separate Ubuntu environments so I would have clean playgrounds for different research topics.  One will be for JAVA/PHP web work.  The second is C++/Qt to play around with algorithms.  The third is a Lucid Lynx (Ubuntu 10.4) to get back to my Operating System research roots by playing around with ChromeOS.  I also spent some time on topcoder.com getting my account back up to speed since I haven't been on the site since 2004.  TopCoder is pretty neat because you can pick what aspect of software development you like and actually compete for real money.  Nothing like getting paid for making yourself smarter.

"Help Wanted"

I have never actually looked for a job before.  Sure, I filled out a bunch of applications at fast food joints when I was 16.  But this is a completely different ball game.  In the past 30 days I have completely rewritten my resume, attended a job fair, interviewed or submitted applications to 25 different companies, and spent hours scouring through job boards and recruiter sites.  Some efforts have gleaned some results.  Others resulted in failure.  Most efforts to date have actually seemed wasted.  The interface to companies are somewhat cold and mechanical.  Even the biggest Fortune 500 companies have shockingly bad job portals.  If you are looking, or thinking about looking, here is what I have seen in the last month:

• Black Holes - Microsoft, Apple, Amazon, and McKesson have shown no sign of intelligent life.  You get a thank you email for submitting to their system.  But after that, you have no way of knowing if you are under consideration or not.  In most of these cases it has been over 21 days without even a courtesy email to say my resume didn't fit.  Follow up phone calls with the recruiters who attended the job fair have also been fruitless.  They seemed interested then, but now is unknown.
• Almost Black Holes - Hewlett Packard (HP) uses Taleo for their job portal which has a decent search interface but gives inconsistent results.  You can pick jobs to track under the job cart and then decide from your cart which ones to apply to.  HP lists over 5000 open positions and shows up at job fairs, so one would think their recruiters would be responsive.  This has not been the case.  I applied for four different positions at HP.  I can see slightly different aspects to each job, but no idea what they mean.  Of the four, one says closed so that is easy.  The other three say active.  I can view/edit/withdraw on one, view/edit on the second, and only view on the 3rd.  I would guess this somehow ties to where I lie in the process, but no idea since no human has tried to reach me.
• Mixed Bag - Google has their own custom job search portal which leaves much to be desired.  You can search jobs and "star" ones you are interested in.  But after that, you have no way of tracking which ones you have applied to or what their status is.  Many jobs have been posted there for years.  I applied to 6 different positions at Google.  One position that included a referral from a Googler got an instant result with engagement from a recruiter and a phone screen.  I apparently did not do so well on the phone screen and they emailed me to say my resume was not a good match and that I could contact them if I had questions.  A) They had my resume before the screen and B) I did ask for feedback and got no response.  I appreciate they can afford to be picky...being rude is another thing.
• Solid - Northrop Grumman and Enterprise Holdings were responsive in both their system design and taking action on the applications.  I would still rate their job portals as mediocre at best.  But at least you can figure out where you stand.
• Recruiters - Useless IMO.  Within hours of indicating I was searching in some key places I started getting phone calls from recruiters.  I put the time in to fill out a profile for them and then never heard a peep.  I get that the job market is tough in some sectors, but it shouldn't be that hard to start lining up Technical Project Manager opportunities.  There are oodles of them listed out there hiring right now.
• LinkedIn and Network - The advice is true that this is your best source if you already have a career in progress.  The people who have actually worked with you know you best and gain pleasure out of helping you succeed.  All four of the interviews and job offers I have received to date have been directly associated with professional contacts.  

Tsugi!

For April, I will be focussed on educating myself.  I plan to get through "Making Things Happen" on the TPM side and "OOP Demystified" on the engineer side.  OOP is a gentle review for me on C++, but will be fun by trying to work through each step in JAVA and C# as well.  Who knows what else the job search will bring as well.

TPM Wisdom

Control the message!  Invariably projects will involve teams and someone on the team will decide to open their mouth.  Never stop hammering into your team the need to keep you in the loop on every conversation and act as an approval point for anything that will get said to the customer.  Failure to do this will generally result in an uncomfortable conversation with the customer where you look like you aren't in control.  The demonstration and sometimes even the illusion of control is what keeps the customer on your side.  It's your responsibility to control what the customer hears.

Who is this for again?

"If it weren't for the customers, this would be a lot easier"
-- The Engineers

Stakeholder Management

No matter what kind of project you are running, the people involved in it are going to be the biggest challenge you face.  Technical Project Managers (TPMs) have it even worse since in many cases part of the project involves creating something that has never existed before.  This creates more than a little bit of chaos that needs to be dealt with.  Although Stakeholder Management has been part of the PMP process forever, it is finally getting more focus by being defined as its own area of knowledge.  In my experience, how you manage stakeholders is the most important part of any project.  If you don't have a handle on that, it's a given that the rest of your project is probably off track as well.

The reason why this is a bigger factor for TPMs is because Engineers tend to be type A personalities who are also easily distracted by shiny objects.  Software Engineering is even worst because Moore's Law applies to more than just semiconductors.  You now have a group of people whose entire world shifts at least once every 18 months.  New languages are invented, old ones are deprecated.  Compiler versions advance and target platforms can change overnight.  Contracts from other customers may even be asking the Engineers to produce the exact opposite functionality.  It is very easy for Engineers to get into a mindset where they are the focal point of all design and forget that customers request things for a reason.  The challenge for the TPM is to get the Engineers in line with the needs of the rest of the stakeholders without self-induced scope creep and without Engineering becoming "those guys".

These are a few of my painful lessons learned on how to make sure Engineering doesn't derail a technical project:

1. Read the Statement Of Work to them - I'm not kidding!  Don't email it and ask if they have questions.  Don't ask for them to mark it up.  Don't put it on sharepoint and then ask who read it.  Somewhere in the unwritten rules for Engineers is a credo that says you don't read the instructions until things start falling apart.  If no one ever forces them to read the SOW, chances are you will have folks doing all kinds of crazy features that they want while crying "Change Order" when you try to get them to do what's actually in the SOW.  Disclaimer to all my Engineering friends (I am one also):  Take a deep breath and remember the first step is admitting you have a problem....we have all done this.  I still love you guys.
2. Let the Engineers outside - I know what you're thinking and yes, I'm serious about this one too.  There is simply no better substitute for letting an Engineer see and touch the problem they are solving first hand.  Obviously provide supervision where needed if the Engineer has extra "people skills".
3. Let the Engineers challenge the SOW - It's OK to let the engineers tell you requirements are stupid or useless.  Sometimes it's just therapeutic.  Sometimes they are dead right.  The software requirements process is messy.  Depending on tons of factors, the SOW could be broken.  A few examples:
• System baselines changed during contracting
• Technology advanced after the sale was closed
• Stakeholder who cared about dot matrix printer support retired
• Sales misunderstood requirements
• Sales was smoking crack (I was also one of these guys...no comment)
• The SOW was written by humans
4. NEVER let the Engineers tell the customer the SOW is stupid or useless - You sadly have to keep an eye on this one.
5. Don't allow double standards on requirements - This one may or may not require some assistance from leadership depending on your relationship to Engineering.  Engineering will pitch a complete fit if you come to them asking for feature X without thoroughly documenting what they should be building.  This is a good thing and I applaud all Engineers who hold TPMs to task on this.  However, watch out if Engineering decides to add or change to feature Y to meet a requirement.  They should be producing the exact same level of documentation for all stakeholders to review.  Otherwise your tree swing comes out four years later as a rocket ship with a picture of a tree swing on it....if you're lucky.
6. Do everything you possibly can to make them part of the team - I'm not saying bribe them...but definitely put some time into building a relationship with them.  Maybe it's blocking off time in the schedule to take them to an early premier of Star Trek XLV.  Maybe you budget a couple hundred bucks for a nice steak (dress code may be a challenge).  Or maybe you find out what tech gadget they are pining for and make it a competitive prize for hitting the finish line on time.  These guys will happily hunker down behind closed doors without regular meals and showers and works their tails off for you.  Sometimes a little forced fun will pay great dividends when tho going gets tough.

The "Golden Rule" of Scheduling

"I'm free in 30 minutes...so surely everyone else is too...right???"- Nearly every PM I have worked with to date

Slow it down please

I'm really not sure why this is such a pervasive habit.  The field of Technical Program/Project Manager (TPM) is naturally a world populated by geeks.  Geeks tend to be more introverted than most and maybe even get used to the instant gratification of their computer doing most everything they ask without delay.  But they are still people and still get irritated when you suddenly interrupt their day.  I can understand a new guy being told to go schedule something and just building something up without checking with others.  But the seasoned folks should theoretically have already been burned enough by others to remember courtesy.  Sadly, this is not the case.

Before any TPM puts a single date on any schedule they need to ask some basic questions:

1. Do I control everyone who needs to participate?
2. Is my project the only thing they are focused on?
3. Is my project their top priority?
4. Do I have visibility of everyone's calendars?
5. Is it possible that some people don't keep their schedules accurate?
6. Can this event succeed if random participants can't attend?

If you answered "No" to even one of those questions, it's time to slow down.  Not everyone realizes that you are the center of their universe.  Taking just a few minutes to make others feel like they are more important than you are goes a long way.  And in the rare case where you are working with folks who actually are more important than you (boss, customer, spouse, etc), then this is even more useful.  Simply send out a request to find out when the team has time available for what you are trying to do.  This can be as simple as a conference call or something more complex like scheduling staff or equipment time.  You can be extra careful and also ask for alternate times so you don't have to repeat emails every time one person has a conflict.  This may feel like it is slowing you down, but it is way less disruptive than botched meetings.  It is also less painful than getting chewed out by a customer or supervisor who felt like you showed a lack of respect for their time. 

Speed it up please

Sometimes emergencies happen.  We have all been there.  Decisions have to be made right away and next Tuesday is not going to cut it.  It is still OK to slow down and ask for available times.  Simply communicate the urgency in your request and let the team know that the meeting will happen with or without full participation.  In these scenarios, it is usually best to follow up your email with immediate phone calls.  Just because you live and die by email and the schedule doesn't mean the whole team does.  Phone calls will catch everything from the Engineer who is in the zone to the executive who is stuck in a critical meeting (aka golfing).

A little courtesy to others will go a long way to keeping your schedule and your sanity intact.

Getting my Geek on!

Before I do anything I want to thank Jonathan Jones, +Brandon Linton, and +Brandon Jones for collective motivation to get out of my computer programming rut.  The last four years or so I have basically only touched a compiler when I couldn't get anyone else to do the coding for me.  I could give tons of cheesy excuses about changing job roles and raising kids, but the truth is I just got lazy.  Boy do I regret that!  I am behind in every possible way and this blog will just be one of the tools I use to start motivating myself to learn and get back my Geek standing.

Purpose

No one who has ever worked with me (except maybe my wife) is buying the lazy bit.  What I have been working way too hard on lately is shaping and managing projects.  What I would like to do with this blog is to mix in my tech R&D with some lessons learned as someone who has had to depend on other developers to deliver a product.  No one ever sent me to school on this or gave me anything that even smelled like an established process for Technical Project Management.  I have learned in the trenches with nothing but my thick skin and stunning good looks to get me through the hard times (you get which one is sarcasm right?).

Disclaimer

I apologize in advance to any future reader who stumbles on my musings and realizes a particular rant is about their project or even about them.  Of course they likely won't read this disclaimer and will flame away. The bottom line is that a few of the lessons I have learned in life have been the result of some fairly spectacular failures.  I will never apologize for being honest.

Hajime!

For the next several days, I will be standing up a Win64 ASP.NET and C# playground.  Why in the world would I pick that you ask?  Because it is something completely new and new is always good.  There is a second reason that I will share in another post.  Never fear though....I am also setting up an Ubuntu 12.10 dev environment to get back into some hard core C++ and maybe even contribute something useful to the open source community.

TPM Wisdom

You don't need PMI, ITIL, ISO, or any other established process to get through a project.  Sure they help, but everyone gets the basic concept of setting a goal and working towards it.  If you are an absolute n00b at project manager, just start with these two basic tasks:

1. Write everything down - I don't mean every word of every conversation.  But do write down the key steps and tasks along the way you did including roughly how long each step took.  Also write down notes about every lesson learned.
2. After Action Meeting - When all the dust settles, you either bought everyone a beer, or walked out the door with all your stuff in a filing box.  Either way, try to get with as many participants as possible and incorporate your writings from step 1 into a written plan for your next project.

Given enough time and projects, anyone will eventually become a master PM just by following those two steps.  Sadly, I have been amazed at how many projects I have watched where nothing is captured or learned from and then everyone seems shocked when the next project is just as screwed up as the last one was.  Baka!