Project Management – Words of Wisdom to the Uninitiated

So, you’ve got your first job as a Project Manager (PM) – congratulations.  Now, you’ve been assigned your first project and you’re looking at the elephant thinking to yourself, what do I do next?  Well, jump in with both feet seems like a good idea – but which end of the pool and how do I tread the water to keep my nose above the waterline?  I’ll attempt to give some advice in this posting – take it for what it’s worth, it may not work for you or your organization, but you may be able to find a nugget in here that gives you a ray of hope!  I know that it has helped me and those individuals that I’ve mentored over the years.

So, most development projects are broken down into phases along the following lines:

1. Discovery – this phase allows you to identify the stakeholders of the project and then working with the stakeholders identify the boundaries of the project, what will and won’t be included in the overall scope of the work.
2. Requirements – this phase allows the team to clearly identify the requirements associated with the project – this should include functional and non-functional requirements.  By the way, this is a personal pet peeve of mine – if requirements don’t include at least a high level explanation of how the user will test/validate that the requirement, then the requirement is not complete.
3. Technical Design – this phase of the project allows the technical side of the organization to take the requirements and translate them into an overall roadmap that identifies the application silos that will be touched and how everything ultimately fits together – this is the roadmap that technical teams will use to build the applications and underlying infrastructure.
4. Development/Construction – this phase of the project allows the teams to construct the functionality that will be delivered as a result of the project.  This should include not only the technical pieces, but the business pieces as well – marketing plans, supporting documentation, etc.
5. Testing – this phase of the project is used to confirm that we have not broken current functionality and that we have validated that the new feature/functions work as documented in the requirements and the technical design.
6. Implementation – this phase of the project allows the teams to move the application and underlying infrastructure changes into the production environment.

Clearly, looking at all of this when you’re first assigned to a project can be overwhelming.  As a PM, how do I know what tasks to put in the project plan and how long do I have those tasks last?

Really, this becomes much simpler than it looks – let’s take the first phase, Discovery.  We understand what needs to be delivered within this phase of the project – in most organizations, it will look something like the following:

• Project Request Document – gives the background justification for the project, a very high level scope of the project used to inform others what is being delivered, extremely high level expenses/costs, extremely high level sales goals, and competitive information.
• Project Concept Document – once the project request is signed off by the stakeholder, this document dives down to give more details – if the project request document was the 100,000 foot view, this takes down to the 50,000 foot view and includes things like the formal project scope/boundaries, project needs analysis, market assessment, proposed timeframes.
• Vendor Due Diligence – this activity confirms that viability of outside parties to deliver critical components of the project.
• Business Case – this takes the Project Concept and builds the other components around the base to provide management with the complete picture allowing them to make the go/no-go decision - sales commitments, revenue projections, product demand and strategic fit information.

Other organizations may drive more or less artifacts through the Discovery phase of the lifecycle.  All that being considered, there are a base set of deliverables that are expected at the end of the Discovery phase.  Additionally, it’s not just a matter of the deliverables/artifacts being generated, it is disseminating that information to the decision makers and getting direction on the go/no-go decision.

So, let’s work backwards – let’s say you’ve been given 3 weeks to perform this activity.  You know that you have to have a meeting with the decision makers at the end to review the information and get the go/no-go decision.  You know that the expectation is to deliver the necessary artifacts 3 days before the meeting.  So if you have a 3 week timetable – that’s a total of 15 business days.  Assume the meeting with the decision makers is held on the last day, that means the documentation must be delivered on the 12th business day.

As the PM, you need to have the following discussions in your phase kick off meeting:

• Who needs to be included in meetings to create each of the deliverables/artifacts – Project Request, Project Concept, Vendor Due Diligence and Business Case?
• We have 12 days to complete each of the artifacts/deliverables for the Discovery Phase – how often do we need to meet on each artifact and how long should each of those meetings last?
• What are the check points in each of these meetings to ensure that we are on track to complete the documents in the required amount of time?

Now you have a timeline to work with – 12 days – and it becomes a matter of accountability.  Setup the meetings, ensure people are attending and contributing.   Your markers for each meeting – make sure you have an agenda, then take and distribute notes:

• Validate that the work that was supposed to be done between meetings was completed.   Get proof – sorry, I tend to be skeptical.
• Review agenda items – check off those items completed, note those not completed and create action/agenda items for next meeting.
• From the review of agenda items – when looking at items that were not completed, are there new risks/issues that need to be highlighted and mitigation plans created or does someone just need to catch up on work assigned?
• Review status updates across the team – ensure people are highlighting what is needed from each other to complete activity needed in this phase of the project.

Sounds simple, right?  Now, as a PM, it’s your responsibility to not to be surprised in your meetings.  While you may be meeting with parts of the team several times a week and the whole team on a weekly basis.  It’s your job to stay on top of things between meetings.  You should never walk into one of the meetings you are holding and have it be the first time you hear that someone is behind schedule.  You need to be performing walkabouts – moving around on the floor, instant messaging, or calling people to discuss how they are doing, what’s working, what’s causing them problems and staying on top of activity.

If between meetings, you become aware of a roadblock – it’s up to you to find ways around, under or over the roadblock and allow people to continue to move the process forward.  Who can you bring into the discussion or work activity to help the person forward?   What work activity can be reassigned?

Now, rinse and repeat for each of the following phases.  The difference being that at the end of the design phase, you should be able to obtain feedback from the team identifying all of the remaining tasks/milestones and timelines for the project.  This then becomes the baseline that you measure everything against.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile

Microsoft and IBM - two giants falling!

I credit the fact that I'm in this industry to Microsoft and IBM.  I was enthralled with the introduction of a small business class computer that you could place on any desk and with the OS and applications that made computers accessible.  Applications like Lotus 1-2-3, VisiCalc, Wordstar and dBase III.  Yes, this was long before the introduction of graphical OS - they all ran on MS-DOS, don't cringe, a text based OS.  And, yes, that means I was playing with these systems shortly after IBM introduced the first IBM PC - the year was 1983 and the IBM PC was only 2 years old.

While attending college, I got a job installing PC's, setting them up and introducing the client to their new system.  I also picked up computers that weren't working properly and brought them back to the service desk to be repaired.  At the time, PASCAL was the language of choice.  I was learning how to program in this language in school and the company I was working for allowed me to take a Compaq Portable PC back to my dorm room.  I convinced my instructors to let me use the Compaq for my programming assignments (I think I was using a copy of Borland Pascal - but my memory is a little hazy) versus having to logon to the DEC PDP 11/70 - a mini computer.  I also was able to get my hands on copies of Microsoft Assembler and Microsoft Basic.  Much as I hate to admit it - that was geek heaven at the time.

I loved the PC and MS-DOS.  Config.sys and AutoExec.Bat were my friends - I knew how to get into these files and make changes to the way that the system operated and the utilities that would be loaded into memory.  Microsoft and IBM made it fun and easy to use these new computers and made programming accessible.  Ask my folks how many hours I spent in front of those early computers teaching myself without realizing how important this would be for the career path that later followed.

I ended up working for a couple of computer resellers early in my career - doing everything from installs, service calls, sales and teaching.  Yes, I actually ended up teaching computer classes on dBase III and Lotus 1-2-3.  Teaching dBase III actually ended up being the precursor that allowed me to get into programming.  I started playing with Clipper - a compiler for the dBase III language.  Then I applied for and got a professional programming job using Clipper.  From there, as they say, the rest is history - moving through my career as a developer, consultant and manager.

None of this would have been possible without IBM and Microsoft partnering together and creating the business class personal computer.  Ask anyone I knew back in those days and you'll hear about how I looked up to these two companies - in my mind, they were at the top of the top, no other company came close to the respect that I held for these two companies.  And my early career was built on this market - migrating to Visual Basic and Visual C++ when Windows took hold.


IBM lost their way and fell down against the IBM compatibles - eventually selling their PC business to Lenovo.  They couldn't figure out a way to compete on cost with the competition.  Go figure, literally, the pinnacle of multinational companies could not figure out how to leverage resources across the world to compete against much smaller companies.  (If you're looking for the full story on IBM's fall - and not just related to PC's - I'll send you to I, Cringely for further reading - The Decline and Fall of IBM.)  IBM is gone from the PC industry and is seeing a decline across their other product lines.  As much as I hate to see this company in the condition it is in, I tend to agree with the assessment that IBM is on it's way down.

Microsoft on the other hand successfully out maneuvered the industry - yes, Apple was there, but they were a niche player.  Along the way, Microsoft made blunders - but was always able to recover.  And why not - they really didn't have any competition, to the point where they were charged and found to be a monopoly. Using their weight to drive competitors out of the market.  Ever hear of the phrase embrace, extend and extinguish?  If you haven't - look it up, it will give you an excellent run down of the way Microsoft controlled the industry.

The first chink in the wall of Microsoft was the open source movement.  Linux in particular and the open source programming languages and tools.  More and more developers became disillusioned with the walled garden of Microsoft and began looking for alternatives - myself included.  Linux, check!  Apache, check!  MySQL, check, Python, check!  All open source, no cost barrier to development or deployment!  What started out as an irritation became a full panic at Microsoft as they ranted about open source being a cancer in the industry.  Today, Linux runs the web.

Then along came the iPhone.  Microsoft initially made jokes about the iPhone - well, that humor came back to bite them in the back end.  The iPhone and iPad have ended the PCs dominance.  I know more and more people that are foregoing the purchase of laptops and desktops at home to purchase 1 or more iPads.  And I'll also wager that Chrome is becoming a bigger and bigger headache for Microsoft.

Apple ruled the smartphone market for several years until Android came along.  The one thing you won't hear is Windows Phone.  Ok, I'll give Microsoft credit Windows Phone isn't bad, but I still prefer iOS.  I'll use Android if I must, but I can never see myself going for Windows phone.

This is where I think Microsoft has really gone nuts - they created Windows 8 to run across phones, tablets and traditional PCs (laptops and desktops).  For those of you that like Win8 - that is your choice.  All I can do is speak for myself and I can not stand this Frankenstein of an OS.  Mindlessly switching me between Metro and traditional windows mode when I want to do various tasks.  I won't go into all of the details, there are plenty of articles out there that get into the details.

Microsoft used to be there for the developer - building the tools and making it easy to get stuff done.  I can't say that anymore.  Developers have moved on to iOS and Android - if it's convenient they'll build a Windows version, but it's usually well after they've developed for the other mobile platforms.  Don't get me wrong, both iOS and the Android environments have their issues, but developers want to be there, not with Microsoft.  And the consumers have spoken as well - at the end of 2013, Windows Phone had a whopping 3% of the world-wide market share of smart phones.

Today's kids want an Android phone or the iPhone - and, yes, that includes my kids.  Do you think when they're ready to move up, that they're going to go with Win8 or with an iPad or a Mac?  Some of them will move to Android tablets.  Fewer and fewer of them are going to choose Win8 machines.

I don't know what Microsoft can do to change the equation.  Is it too late?  Well, the good news is Microsoft has a lot of money in the bank, they've realized that Balmer was leading them off a cliff and have replaced him, and they still have a following.  Will something change in the equation - who knows, but if I was a betting man, I'd say Microsoft will never have the power or control that they had in the 90's and early 2000's.

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile