Tactical PM Blog
twitter-blue35x36 microsoft project training facebook page ms project tutorial video

Agile Software Development - Rational Software Mini Conference

Print E-mail
Written by Dr. Andrew Makar   
AddThis Social Bookmark Button

I'm attending a mini-software development conference host by IBM at Michigan State University in East Lansing, Michigan.

The conference is only two days and I'll be tweeting a few bits of advice and updating this article with the key takeways from the various sessions on Agile software development using IBM's Rational tool suite.

If you want to follow along in real-time, just follow me @andymakar on Twitter or you can view all the postings by searching for the hash tag: #ibmmsu via Twitter

Here is the link with the latest Twitter posts and bits of advice from the Rational Software Development Mini-Conference

Key Note Take Away

Tuesday's keynote presentation focused on the importance of delivering a quality product versus delivering a best in class software development method.  As software developers, we often think about the best process to develop software.  Software is just part of the solution as the entire product needs to consider not only the software time to market but the business functions they support.

An interesting fact was the presentation cited only 34% of all software projects are successful at the cost of $300 Billion.  Can you imagine what the failed projects cost?  The keynote also emphasized the need for iterative development as a product is developed.

Agility at Scale

Lee Reid gave an interesting presentation on an Agile Software Development Maturity Model that highlighted the different stages organizations experience as they adopt Agile.  Not suprisingly, a lot of waterfall organizations have needs at the most mature stages of the maturity model although they need to start at the first level of Agile Maturity.

The maturity model presented provides a roadmap for organizations to adopt Agile best practices.  An interestng fact was IBM has transitioned their software development process to embrace agile concepts using their own Rational products to improve collaboration.

The presentation also highlighted the concepts in the http://www.agilemanifesto.org and new concepts for software craftsmanship and community at http://manifesto.softwarecraftsmanship.org

It was also refereshing to learn IBM recommends a variety of techniques to elicit requirements including use cases, user stories and short statements to define requirements.  I've seen some organizations that have methodologies that require EVERYTHING to be modeled instead of focusing on the critical or complex requirements.

Here is the link for the Agility at Scale presentation.

Rational IBM Team Concert

Rational Team Concert is an interesting idea as a collaboration platform across developers.  It has a lot of functionality although my perspecitve is it has a big learning curve.  Incorporating instant messaging, release planning, iteration planning and various agile components in one Eclipse-like platform is an impressive set of features.  However, I thought the demo was a difficult to navigate.

Compared to VersionOne or RallyDev, the Team Concert had a lot more complexity and I felt like I'd was searching and pecking for the specific features.  As a collaboration platform, I thought a better UI would encourage collaboration not only from the development team but from the product owner.  VersionOne and RallyDev have a different approach that makes collaborating around Agile seem easier.  I only spent an hour with the demonstration and I believe a development team would have a different perspective.  The Jazz concept is a useful product for collaboration indepedent of the Rational Tool set.

The other observation is the solution set for IBM software development seems quite LARGE. Instead of purchasing 1 product that supports requirements, quality management and software processes, you'll need to purchase all the solutions to effectively maximize your efficiency.  I appreciate having a lot of different products but with every product comes a learning curve that even enterprise organizations will struggle adopting.

I thought the concept was exciting and I like the idea of cross team collaboration.  However, I've seen other software products execute the solution better.

Good Requirements

The next session was on establishing Good Requirements.  Lee Reid faciliated the discussion and he had a good perspective on requirements definition and requirements managment.  I liked the model he drew on the chalkboard (yes..a chalkboard at MSU vs. a whiteboard...I haven't seen one of those in a while).  The key points included:

  • requirement issues drive excessive rework, delays, poor quality and project failures
  • time not spent in requirements is time spent in rework at cost X 200
  • business req: the user shall be able to...
  • system requirement: the system will do..
  • a good requirement depends on WHO is reading it
  • requirement confusion occurs when we mix the problem space with the solution space
  • it is important to realize projects don't need to apply all types of requirement elicitation techniques. Pick 1 or 2 and augment

I found it interesting that the requirements management and requirements definition presentation didn't integrate Agile with the presentation.
Often when we talk about requirements management, we ask "Where is the approved business requirements" and defend any changes to the "signed off" requirements.  The reality is requirements evolve through a project and and good requirements need to embrace flexible processes that allow requirements to elaborate and change.  The key note presentation addressed the need to build software incrementally.  Requirement processes also need to adopt this focus...otherwise you're faced with a 200 page requiremement document that the business customer has no interest in reading.  In all honesty, neither does the project team.

Here is the presentation on IBM's Good Requirements

Overall, the first day was very informative and I enjoyed learning how IBM is "moving the needle" with improved collaboration and better software development practices.

Add a comment
 

Schedule Management: The Myth of 90 Percent Complete

Print E-mail
Written by Dr. Andrew Makar   
AddThis Social Bookmark Button

The Schedule Management Problem

A typical team status meeting includes the project manager reviewing the work plan and asking team members to report on relevant task progress in the work plan. A typical response from team members is "The task is 90 percent complete," or some variable percent. Project managers can make the mistake of assuming a status of "90 percent complete" is an effective method to monitor task progress.

Using a status of 90 percent, the project manager updates the project plan and communicates to the stakeholders that the particular deliverable is 90 percent complete. Everyone feels comfortable about the number and they move on to the next status item. Another week goes by, and at the next status meeting, the task is still 90 percent complete with "just a little more work to go."

When the project manager asks why the deliverable wasn't completed, the team member responds with a list of other tasks or dependencies that are needed to complete the task. In the interest of a short status meeting, the project manager leaves the deliverable at 90 percent complete until next week. This cycle can continue week after week as the deliverable continues to fall further behind in the project schedule.

 

The "90 percent complete" approach to deliverable tracking is entirely subjective. The percent complete approach represents a quick estimate of deliverable status based on a team member's feeling or intuition. This approach doesn't provide the project manager with any information about actual task effort or forecasted end dates. The problem is further propagated when project stakeholders communicate the same status to their colleagues.


Recommended Schedule Management Solution

 

A recommended approach is to avoid the subjective view of task status and implement an objective one. In order to objectively measure project schedule and cost performance, the project manager needs to know the following:

 

  1. When was the task scheduled to start and complete?
  2. What was the original task effort?
  3. When did the work actually start?
  4. How many hours have been spent on the task?
  5. How many hours are remaining?

 

The first two questions can be answered by examining the project baseline. The project baseline is the official record of cost, scope and timing for each deliverable in the work plan. Once project managers understand the original task effort, baseline start and finish dates the project manager can inquire about the actual work spent on the task.

 

The project manager uses the data to calculate an objective measure of work complete and, more importantly, forecast a task end date based on the remaining effort.

 

Task Percent Complete = Actual Hours Spent / Baseline Work (+/-) Remaining Work


Task Baseline Information

Task Status Tracking

Baseline Effort: 80 hours

Baseline Start: 7/5/2004

Baseline Finish: 7/19/2004

Actual Start: 7/7/2004

Actual Hours Spent: 60 hours

Remaining Work: 40 hours

Forecasted End Date: 7/24/2004

Task Percent Complete = 60 hours / (60 hours + 40 hours) = 60% complete

 

In this example, the original effort was 80 hours and actual work required was 100 hours.

 

The task also started two days later and the additional 20 hours added another 2.5 days to the task schedule. If the project manager did not ask these questions and accepted a subjective 90 percent complete, the project manager would have assumed 54 hours have been spent with 6 hours to complete the task.


Benefits


Tracking project actuals provides the following benefits:

  • Improves project status reporting using accurate and objective task end dates.
  • Improves project status reporting by communicating an objective percent complete instead of a subjective percent complete.
  • Improves future project estimation accuracy by comparing project baseline work and actual work.
  • Avoids "guesstimate" approach and uses project data to forecast project completion dates.


Challenges and Road Blocks

 

If the project team is new to this approach, the project manager may experience some push back or reluctance to provides estimates. A common fear is the team member may face negative consequences for failing to complete the work in the estimated amount of time. Other team members simply don't want to escape the comfort zone of reporting "Its about 90 percent complete with a little more work to do."

 

To overcome the pushback, the project manger should encourage a work environment where missing estimates is not punished although meeting estimates is encouraged. If project managers experience resistance, an effective technique is to break down the work into smaller chunks and translate end dates into project effort. Asking a team member if they can complete the work in 3 days translates to 24 hours of work in the project plan. If they are only available to work on the task 4 hours each day, then the 24 hours of work stays the same but the duration increases to 6 days.

 

Project team members may indicate providing estimates of actual work remaining is also subjective. The original project estimate was a prediction of effort based on team members' experience and available information. During project execution, team members know more about the project's tasks and remaining effort. The actual work remaining is based on more information then when the estimate was provided. As tasks progress, providing estimates will be easier since the team knows more about the tasks and remaining effort and related issues.

 

Conclusion

 

Regardless of your project tracking tool, ask your teams for the amount of time spent and the amount of time remaining for each task in your workplan. Ask the five forementioned questions to identify when work started and forecast how much work is remaining. Avoid the subjective nature of reporting "90 percent complete with a little more to go."

 

In our original scenario, the project manager reported a status of 90 percent complete using the subjective guesses from project team members. After recording objective project actuals, the project plan may still indicate the same percentage, but the project manager knows it was calculated correctly and the forecasted dates are effort-driven instead of subjective guesstimates.

 

Simply reporting the percent complete isn't enough to provide accurate and data-driven end dates. Project managers that follow an objective schedule updating approach will benefit from improved project control and monitoring. The approach also provides a repository of actual effort that can be reused to estimate future project's cost and timing.

 

Authors Note: I wrote this article in October 2004 and originally published it on www.gantthead.comCheck out gantthead.com for more additional project management resources.  They have some great stuff!

Add a comment
 

The One Page Project Manager

Print E-mail
Written by Dr. Andrew Makar   
AddThis Social Bookmark Button

The One Page Project Manager has an interesting premise - What if you could communicate and manage an entire project using one sheet of paper? The author, Clark Campbell, provides a template and the mechanics of adding milestones, issues, risks to provide an overall summary of the project. The data tracks all the major aspects of a project on a simple page. We often manage complex projects and the ability to clearly communicate key details, engage with stakeholders, and successfully track progress is a useful feature condensed into a single sheet of paper.

Mr. Campbell offers two books using this approach - one for general project management and one for IT project Management. If you're looking for a simple way to reference the latest project status and simplify communication, check out the book. I enjoyed it.

Check 'em out at:

  1. The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper
  2. The One Page Project Manager for IT Projects: Communicate and Manage Any Project With A Single Sheet of Paper
Add a comment
 

Tactical PM Tips Newsletter: Project Management and Twitter

Print E-mail
Written by Dr. Andrew Makar   
AddThis Social Bookmark Button
In this Tactical Tips issue, Tactical Project Management presents:

• Project Management and Twitter
• PM Tip: Get your latest PM news using Google Reader
• Recommended Reading

News You Can Use

Project Management and Twitter

My search for social media applications for project management continues to identify additional tools that project managers can use to enhance their learning and improve collaboration with a worldwide community of practice. If you study social media, you can't go too far before learning about Twitter. I written about the topic and its application to project management learning is a useful one.

I don't use Twitter to learn about where my friends are at, what they are doing, or their latest witty comment or outlook on life. Facebook is a much better application to keep in touch with friends and keep your personal life...well...personal. I DO use Twitter to learn about what other project managers are doing, what they are reading, and asking questions through my project management network. Twitter operates on a simply concept of distribution 140 word characters to everyone who is following you.

As a guideline, I only follow project managers or people who produce useful project management content. As a result, anytime someone I'm following sends a "tweet", I quickly get a 140 character description of the project management snippet. If I want to learn more, there is usually a URL included. This approach quite simply saves time and when someone I value sends a tweet, I'm more likely to look at it.

If you want to jumpstart your Twitter and Project Management follow list, I recommend you follow these project management practitioners:

Dave Garrett @DaveG253
Naomi Caietti @califgirl232
Elizabeth Harrin @Pm4girls
Elyse Nielsen @anticlue
Cornelius Ficht @corneliusficht
Andy Makar @andymakar

(yes I had to include my own plug...)

For a quick overview on Twitter for business checkout:
A quick Twitter guide and glossary for business users

Upcoming Mind Jet Mind Manager Webinar

Please mark your calendars for September 10th for an upcoming webinar on mind mapping and project management with MindJet Mind Manager. I've been asked to co-present so I look forward to seeing you virtually on the seminar! It is a no-cost webinar that will highlight mind mapping and project management in action. Stay tuned for more details. Once the registration URL is live, I'll let you know.

Tactical Project Management Tip

Get your latest PM news using Google Reader

If you want to keep up with the latest project management news in our industry, give Google Reader a try. Google Reader is a Really Simply Syndication (RSS) reader that simply aggregates the latest news feeds into one easy to read view. If you find a favorite project management website like (ahem) http://www.tacticalprojectmanagement.com, you can add its RSS feed to your Google Reader. Instead of visiting multiple websites to get your latest project management news, articles or tips, I just use Google Reader to get a preview of all the relevant articles.

You can access Google Reader by visiting http://reader.google.com
Below are just a few of the RSS feeds that I recommend. Just copy the RSS link into your Google Reader.

Hearding Cats http://feeds.feedburner.com/typepad/HerdingCats

Gantthead http://www.gantthead.com/RSS/gantthead.xml

Projects@Work http://www.projectsatwork.com/RSS/projectsatwork.xml

Tactical Project Management Blog http://www.tacticalprojectmanagement.com/tactical-tips/feed/rss.html

Did I mention that Google Reader looks great on the iPhone? The majority of my reading is done via the iPhone while waiting in-line or during those "deadspots" in meetings. (I'll let you define your own deadspots as some poorly run meetings can consist entirely of deadspots).

Recommended Reading: One Page Project Manager

The One Page Project Manager is an interesting premise - What if you could communicate and manage an entire project using one sheet of paper? The author, Clark Campbell, provides a template and the mechanics of adding milestones, issues, risks to provide an overall summary of the project. The data tracks all the major aspects of a project on a simple page. We often manage complex projects and the ability to clearly communicate key details, engage with stakeholders, and successfully track progress is a useful feature condensed into a single sheet of paper.

Mr. Campbell offers two books using this approach - one for general project management and one for IT project Management. If you're looking for a simple way to reference the latest project status and simplify communication, check out the book. I enjoyed it.

Check 'em out at:

  1. The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper
  2. The One Page Project Manager for IT Projects: Communicate and Manage Any Project With A Single Sheet of Paper

Hope the rest of your week is a good one!

Thanks!

Andy
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
http://www.twitter.com/andymakar
http://www.tacticalprojectmanagement.com

MS Project Tutorial - Learn how to EFFECTIVELY develop a Project Schedule

 

Add a comment
 

MS Project Tutorial: Earned Value Management Checklist

Print E-mail
Written by Dr. Andrew Makar   
AddThis Social Bookmark Button
Over the past nine years, I've been studying earned value management (EVM) and its application to IT projects. According to PMI's Project Management Body of Knowledge, EVM is an "objective method to measure project performance in terms of scope, time and cost." If you're unfamiliar with EVM, read my overview before proceeding with EVM metrics in Microsoft Project.

EVM metrics are easy to calculate, as it only requires simple math. According to industry research, there are 40 critical success factors to successfully implement EVM in an organization. One of those critical success factors is the project management team can develop a project schedule and track against a project baseline. A properly developed Microsoft Project Schedule is critical in calculating EVM metrics when using Microsoft Project. A poorly defined Project Schedule will result in poor EVM metrics.

The following is a quick checklist to confirm your Microsoft Project Schedule is ready for EVM.

  1. Confirm the Work Breakdown Structure (WBS) has been correctly defined with the appropriate work packages
    Meaningful earned value metrics are only as relevant as the tasks they represent. If you've built a poorly defined WBS, earned value can't help you.
  2. Confirm the work resources have the appropriate hourly rates in the Resource Sheet view
    Microsoft Project determines the work package's budget based on each assigned work resource's hourly rate. If you don't have a defined cost for each resource, your budget will be zero.
  3. Confirm all tasks have resources assigned at the lowest level in the WBS
    A task establishes its baseline budget and planned value (PV) based on the resource costs assigned to the task. By ensuring resources are assigned to the lowest level in each work package, the cost will roll up appropriately.
  4. Confirm no resources are over allocated
    Despite our desire to give 110%, a realistic schedule has resources only allocated 100% of the time.
  5. Confirm the total costs for each work package match contractual agreements
    Microsoft Project builds a time-phased budget for each task and allocates planned work and costs according to the project calendar. If your project contracted for $100,000, the total cost in the WBS should reflect $100,000.
  6. Confirm the project has a project baseline
    The project baseline establishes the time-phased budget for the project and allows PV to be calculated. If you don't baseline the project, you can't measure what you're trying to manage.
  7. Confirm the project management staff understands the procedures to record actual start, finish, duration, and costs data for the project schedule
    As the project progresses, it is important that anyone updating the project schedule follows a consistent procedure to record start dates and actual costs. If teams use inconsistent practices, your earned value results may be off.
  8. Confirm the project status date is set in Microsoft Project before examining EVM metrics

If you don't specify the project status date, Microsoft Project will assume the current date is the date used for calculating the earned value metrics. Since status reporting usually follows the prior week, you'll want to set the project status date each week to calculate accurate metrics.

If you are interested in the EVM topic further, I recommend these three books:

Add a comment
 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 9 of 16
Joomla Templates by Joomlashack