Category Archives: Program Management

My PM “Piece de Resistance”

Have you ever thought back on your project management career and find that one project that just rings true?  That it was because of your efforts, ideas and fortitude that you were able to motivate the team and through a “Team Effort” bring the project to a successful completion.

Well, I looked back at a troubled project that I was brought in to rescue.  The client laughed when I asked if I could see the last 3 months of status reports, it had been months since one went out.  The project plan had not been updated in the same period of time.  I thought to myself that this is definitely a ship without a rudder.

It was time to go “Old School” on the team.  My favorite project management approach is to take brown butcher paper and tape it on a wall (or in this case I used several of the large flip chart pages taped together).  I brought the team in to the room and had them sit down.  I told them that this is a team building event.  It was up to us to bring this project in on time and together we were going to work out the details.

I told them that we were going brainstorm and come up with all the tasks that needed to be done and that I was going to write them down on multi-colored 3 inch post-it® and stick them on the wall.  A different color would represent the different process streams (e.g. light blue = functional, green = technical, purple = training, orange = communications, magenta = conversion, etc.)  Each post-it was then had a line 2/3rds the way down and then again 2/3 the way across that to form 3 sizes of boxes on each post-it®.  In the large box I would write down the task that needed to be completed.  In the second largest box I would write down the “responsible party” – this is the person reporting back to me on the status of the task and not necessarily the person or team doing the task).  In the small box I would ask for the duration of the task and not the effort.  Knowing that many of the people on the project had “other” work to do, I was more concerned with how many days a task would take to complete (e.g. an 8 hour task being done in 3 days due to other obligations).

After the team brainstormed all of the multicolored tasks, I put a yellow post-it® on a 90 degree angle on the left side of the assembled flip chart paper and wrote the word “Start” and another on the right side of the paper and wrote “Finish”.  I looked at all of the colored notes and asked the question “if we were to start today, what would be the very first thing we could do?”  After hearing a couple of the responses that represented different process streams, I took each of those notes and placed them to the right of the “Start”.  I then drew lines from the “Start” task to these tasks.  I asked “are there any other tasks that could be started.  And a few more suggestions went up.  I then repeatedly asked “what is next?”  I would put the task up on the sheet and draw the appropriate lines.  Of course, one task could have several lines drawn from it to represent the one-to-many relationships or the possibility of many task lines to one task (many-to-one).

At first I saw some confused faces, I could tell that they did not know exactly what we were doing, but before long, I had several people up and putting the tasks on the board and drawing lines to make the connections.  I had them write on the lines if the relationships between the tasks are F/S (Finish to Start), S/S (Start to Start), or F/F (Finish to Finish).  Before long we had our network diagram completed.

I then had everyone leave while I then put the network diagram that we just completed into MS Project to determine the critical path as well as the estimated completion date.  We then met the next day and I had the project plan up on the projector with the critical path highlighted.  I said this part will require some more attention to detail.  Our “plan” had us finishing in over 60 days and I told them our goal is to compress the plan to what is truly realizable.  We looked at the critical path at the largest duration task.  I asked if we could make this in 10 days versus 13 days.  The conversion team agreed to this.  Recomputed the plan and now we took a look at the next biggest duration task . . .and so on and so on.  We finally got the plan down to 45 days and we all agreed that this was realistic.  With big smiles, we had our plan and I managed to that plan.

 Everyone enjoyed the experience, they felt committed to the project, and we used that same process for the detailed cutover plan.  We put the cutover plan on the wall of the “War Room” and would put a “/” through the post-it® when we started the task and an “X” when we completed the task.  Everyone could visually see where we stood on the cutover process, what the next task to be done and if we were on schedule.  This type of planning works and I try to use it on all of my projects. 

I was proud of the project, the team, and myself to make it the success story that it was.

11 Comments

Filed under PM Tips and Tricks, Program Management

Agile Project Management: The New Software Methodology?

This is my impression of Agile Project Management:

Agile Project Management . . . What is it?

Agile programming breaks down an application development project into smaller modularized pieces.

»      Each piece is addressed one at a time in a very short time frame (called a sprint). This adds to the application and represents a complete part of the functionality.

»      You can deploy the application and expect people to accomplish some amount of work with it, even if the application does not do everything that is intended upon full completion.

agile13

For example, if you were creating a word processor, one iteration might be its spellchecker. The spellchecker adds functionality to the word processor, but it affects only one aspect of the application.

Before the developers create the iteration that handles spelling, users can work with the word processor without that feature in place.  They simply cannot perform a spell-check on what they write.

Reasons to use Agile Project Management

Businesses need a way to reduce development costs, improve software reliability, decrease time to development and ensure applications actually work with the users, rather than against them.  Reducing the number of errors developers make when designing and building applications.

In addition, Agile programming techniques can eliminate that most expensive development cost of all: the failed application.  Source: www.CIO.com : ABC: An Introduction to Agile Programming

Agile Project Management  :  A Scrum Iteration Example

 agile2

Scrum (the word “Scrum” comes from a terminology in Rugby) is a management-focused agile methodology that is straightforward and can be used in a wide variety of project environments. The Scrum methodology provides the guidance necessary to direct a project in an environment of high variability and where some departments within the customer may have conflicting or competing interests.  Of all of the Agile methods, SCRUM appears to be the most popular.  The daily communication engages the stakeholders. Scrum requires that the customer not meddle with the team while in sprint and accept that the team may alter sprint goals as required by the difficulty or ease of its tasks. Scrum out-of-the-box is formulated for smaller teams. However, it comes packaged with a scaling strategy, based on a Scrum of Scrums, that is claimed to have been applied to an 800-person project

Product Backlog: team converts the features requested by the customer into a list called the sprint backlog of specific and estimated tasks

Sprint Planning Meeting: The sprint planning meeting is actually two meetings that are timeboxed to four hours each and meant to be completed within the same day. In the first meeting the team assists the customer (called the product owner in Scrum) in selecting the functionality for the upcoming sprint. In the second meeting, the team converts the features requested by the customer into a list called the sprint backlog of specific and estimated tasks

Sprint: Timeboxing is an important feature of the 30-day sprint. This forces tough decisions about functionality and design. The more things different customers request at once, the longer it will take for the project to produce anything of value; meanwhile, there is always a more elegant design solution if the programmers would keep looking. The timeboxed sprint keeps the team from entering into such low-productivity quagmires by forcing the customers to agree on the features the team will produce in the next 30 days and by giving the team a hard deadline to deliver as much of those features as possible.

Daily Scrum: Scrum uses the daily Scrum meeting (short in duration), which facilitates daily communication from the programmers on the project to the otherwise unengaged stakeholders. This meeting ensures that the team communicates frequently, that no one ever wanders far off course, and that customers are made aware of roadblocks in a timely manner.

I hope this was informative in giving you a look at Agile Programming. 

3 Comments

Filed under General, Program Management