Jan 27 2012

Why Foundational Features Matter

Let’s say you know customers need a really complex feature, but your project team only has time for a basic implementation.  Do you wait until you have team resources to build the full implementation?  Or do you just build a basic foundational product that doesn’t actually meet any current customer requiments?

My answer: Start with the basics.  Add later.

Foundational product features are usually enough to sell the full implementation.  Customers can see that you have a percentage of what they need.  That helps them have faith in a full implementation at a later time.  They know it’s just a derivative of your current implementation.  But without something tangible to demonstrate, they won’t believe you’ll do the feature at all.

No responses yet

Jan 26 2012

Phased Product Releases

Published by newshirt under Product development

What do you do when you find yourself in the middle of a deep product feature hole?  I’m talking about developing a new feature that you find is taking four times as long as you originally thought it would.

For project managers like me, panic sets in…

Here’s why: Having the product readily releasable is the absolute highest priority.  Deep dives jeopardize that.

So here’s what I’m going to do for this particular feature.  Reluctantly, I’m going to release it over four product releases.  Here’s how I’ll phase it out:

        1. Database plumbing (already released two weeks ago)
        2. Middleware, or business logic plumbing (next week)
        3. Basic feature functionality (a while later)
        4. Full feature functionality (a bit later yet)

–newshirt

No responses yet

Jan 24 2012

Trust Me, I’m a P.M.

An often overlooked step in the project management team is the project/client representative. The person responsible for being the messenger, intermediary between the project team and the client is a critical role. Larger companies pay professionals to strictly fill this role, while smaller companies often let the PM handle that role. This is fine in most cases, unless your PM is not good at customer relations. Customer relations’ professionals spend their entire day thinking of how to build trust, gain confidence, and maintain a relationship. Project managers spend their day doing this on some level within their project team, but it is not their main focus. If you are good at customer relations it will make the project run smoother because the client will have a certain level of trust. If you are not, the project becomes hindered. Why? Because, the client doesn’t have a needed level of trust in you, they begin to question your work. Now the client wants more status meetings. Maybe the client begins to micromanage your project and requires more of the project manager’s time and attention? This can quickly snowball because of one misunderstood statement that breaks a fragile trust. Whoever is communicating with the client, make sure it isn’t General Patton. While he gets the job done, in the project world he would make the job more difficult.

No responses yet

Jan 20 2012

Henry Ford on Competition

Published by raywhite under Business

The competitor to be feared is one who never bothers about you at all, but goes on making his own business better all the time. — Henry Ford.

No responses yet

Jan 19 2012

U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

No responses yet

Jan 18 2012

Groupthink…Project Killer

Susan Cain just wrote a piece in the NY Times talking about the destructive force of groupthink (article found here: http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all). This started me thinking how groupthink applies to project management and the synergy created or hampered within a project team.
After reading the article I am more convinced that as a project manager it is important to encourage and draw out people’s experience and opinions. It is imperative that project teams have a voice and strong leadership to maintain project goals while remaining open to the team voices. Otherwise, we have the inverse problem. Instead of shortsighted groupthink that has little innovation and a blind rudder. You get analysis paralysis where the goal is clear but the wheels just spin. Which is worse? Probably about the same…nothing gets done, or it does, but it is completely wrong and misses the mark. What do you think?

No responses yet

Jan 16 2012

Define: Material resource

Published by newshirt under Definitions, Microsoft Project

Material resource: A non-human, quantifyable substance assigned to project tasks.

Material resources are assigned to project tasks, but are not human resources.  They are any quantifyable material used to complete the task.  The image below illustrates.  In this example, 40 yards of sod are used in completing the “Lay sod” task.

–newshirt

No responses yet

Jan 12 2012

Earned Value Increases As It Travels

Published by raywhite under Business

Earned value (or the value you receive on your intellectual property) increases as it travels through the supply chain.  In other words, the farther an item travels from the manufacturer to the consumer, the more value it brings the manufacturer.  Consumer items change hands many times before they end up in consumer’s hands.  Each time they change hands, more money is invested, and therefore the value goes up.

Consider the illustration below.  A single egg isn’t worth much until it is developed.  Its value rises 100 times from nest to table.

Have you ever considered that software does the same thing?  It earns value as it passes from idea to developer, to QA, to packaging, to reseller, and finally to consumer.  So, the true Earned Value of a product is dependent upon its position in the supply chain, not just at the coder’s keyboard.  You account for such value by quantifying your products on their route to the consumer.

No responses yet

Jan 10 2012

Ever Have One of Those Meetings?

I was in an important meeting and the project team pretty much knew that a certain person wasn’t carrying their weight. This person wasn’t a complete let down…but could do more. During the course of our project meeting an issue was raised as to why a task had not been completed. This person became defensive and started pointing fingers and making excuses. I lost it. A normally mild manner person, I let him have it. I gave him the what for and how come. However, I was out of line and spent hours in one on one meetings apologizing to this person and the rest of the team. There is a time to kick someone in the pants and a way to do it. My way that day was wrong. It costs our team more time in apologizing then this person not completing their task. The bottom line is we have to play the game with the team that we have. There isn’t always time to replace someone and many times there isn’t anyone else available…period. My advice…if you aren’t getting the job done, own it and move on. People respect that more than excuses. Secondly, be slow to speak or you may make a situation worse. I know, because I did

2 responses so far

Jan 05 2012

What’s the difference between ‘Duration’ and ‘Work’?

Published by raywhite under Definitions, Microsoft Project

What’s the difference between MS Project ‘Duration’ and ‘Work’ fields?  The image below probably explains it all.  It’s a simple task from Microsoft Project that shows both the ‘Duration’ and ‘Work’ columns.

 

Task Duration

 

As you can see ‘Duration’ defines the calendar time that the task will be worked on, while ‘Work’ defines the number of man-hours.  In this case, Frank is scheduled to work only 40 hours over the next four weeks.  That’s only 25% of his scheduled hours.

 

No responses yet

Jan 04 2012

Negotiating and Managing Project Expectations

One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?

One response so far

Jan 03 2012

Daily Scrum in 1910?

Warren mentions Henry Gantt’s desire to update project schedules daily (see post of Dec 27, 2011 http://www.projectteamblog.com/?p=190).  He met with his team daily!  I find that refreshingly visionary.  Gantt is seeing a hundred years into the future, and doing things the right way.  He’s staying on top of things in his own 19th Century way.

Sure, Gantt’s daily meetings were not the same as a Daily Scrum meeting — Scrum is not a warmed-over Gantt chart.  Gantt was simply reminding his team of the project schedule and tasks ahead, and updating his new-style chart to reflect the conditions on the ground.

That effort alone — the daily meeting — probably accounts for 75% of the success of any project.  Three cheers for Henry Gantt — 1861-1919!

 

–newshirt

No responses yet

Dec 27 2011

The Gantt Chart and Daily Project Coordination

All project managers have used or at least heard of a Gantt chart. The Gantt chart was created by Henry Gantt around 1910 and still widely used today. It was used in major projects like the Hoover Dam. Henry Gantt designed the Gantt chart to help manage project scheduling and work progress. If you read his book, Work, Wages, and Profits (1916), you will note that Gantt believed it was imperative to communicate daily schedules to key players and by not doing so rendered schedules useless. Gantt thought it was important to be a project coordinator, to coordinate activities, and reduce conflicts. I think this is an important and often overlooked part of being a project manager. We often look at the larger picture and fail to identify “Daily” influences that cause project slowdowns. We should have daily expectations and identify barriers to those expectations each and every day.

Reference:
Gantt, H. L. (1916). Work, wages, and profits. San Diego, California: University of California Libraries.

No responses yet

Dec 22 2011

Project Driveway Snow

Published by warren under Uncategorized

So I got home around 10:30 last night and there already was about four inches of snow on the ground. As I pulled into my garage, I know my truck is packing the snow on the driveway into hard ice. That is nearly impossible to get up. Then I thought…hey this is a job for the Project-team blog. Before I hit the sack I sketched out a rough project plan to start first thing in the morning.

6:00A.M.- emailed the team to begin the day announcing immediate project escalation for driveway snow removal by end of day.

Pete, my lead engineer: The driveway is 25’ x 40’ long and the snow is 6 inches deep. Please determine the cubic feet of snow removal and determine the most cost efficient shovel for the job. Oh, and we may have packed ice under snow. Find a tool for that, too.

John, our labor liaison: Get with Pete and determine the number of man hours needed to remove the snow…will we need one, two…three labor resources to complete on time? Remember, we need the job finished by 5pm today. Please provide estimated labor expense accordingly.

Les, in materials procurement: Please let Pete know if any ice melt is available. Please advise as to whether there are any has mat concerns and what costs are associated with procurement.

To All: I will be on site to assess progress and will be available throughout the morning. The plan is to begin removal by noon…let’s get to work…my wife has Christmas shopping to finish!

9:00AM: received message from Pete. He has located a shovel at Lowes for $15.99 and a tile remover for the ice, $34.99.

Pete: please get a P.O. together and have Dave Johnson and Allison Fields sign off immediately. We need their signatures by 10:30 A.M. because Betty Thomas (CFO) has an 11:00 AM. and is heading straight to the airport for Christmas break. We have to have Betty’s final approval before we can purchase equipment from Lowes.

10:00AM: John sent IM stating we can only get one labor resource because all the others are currently working at 98% capacity. We can only have the one available person from 2-4pm.

10:15AM: Pete: Just ran the numbers and we can have the ice removed utilizing one person in 3.5 hrs.

10:20AM: I replied to Pete…SCOPE CHANGE! I forgot we need to include the front side walk and porch. We are talking an additional 70 square feet! Please get back to me on man hours needed.

10:40AM: Message from Pete: We will need an additional 30 minutes for the sidewalk and porch… almost a 15% increase. I will get with John and see if we can secure additional resources.

11:00AM: Email to Pete…Have you got the P.O. approved…what is your ETA for getting equipment to site?

11:10AM: reply from Pete: We only have Allison’s signature, Dave is out sick. I will need to get Eric Jansen to sign off in place of Dave. Then I still have to catch Betty for her signature…working on it!

11:45 AM: Message from Pete: I have Dave’s signature trying to catch Betty before she leaves the building.

12:20PM: Message from John: I can’t get additional resources. I know we are behind on our project plan, but it looks like we have to go with what we have.

12:27PM: Message from Pete: It looks like I missed Betty, her 11:00 A.M. meeting was cancelled and she took an early flight. Can you get a petty cash disbursement for the equipment? (I don’t know why I didn’t think of that sooner!)

12:30PM: My reply to all:

Project Snow Team,
Due to a minor scope change and lack of funding the snow removal project has been delayed and it looks like I will just have to do it myself. Take the rest of the day off and have a Merry Christmas!

No responses yet

Dec 22 2011

How to use Overtime in MS Project

Published by newshirt under How-to

Admittedly, overtime is a clunky feature in Microsoft Project.  I like the simplicity of Standard Time better.  But here are some steps to help understand and master overtime usage in MSP.

Start by assigning resources to your tasks.

  1. Right-click in a column header
  2. Choose Insert Column…
  3. Insert the ‘Resources’ column
  4. Enter names for employees that will work on each task

Assign cost rates to resources

  1. Choose View, Resource Sheet
  2. Enter currency rates for ‘Std.’ and ‘Ovt.’

Enter overtime hours

  1. Choose View, Task Usage
  2. Right-click and insert ‘Work’, ‘Cost’, ‘Overtime Work’, and ‘Overtime Cost’ columns
  3. Enter hours for the Work column
  4. Enter a portion of those hours that will represent overtime work

You will notice that the ‘Duration’ value shrinks for tasks with overtime hours, and that the ‘Cost’ and ‘Overtime Cost’ values are update accordingly.

 

–newshirt

No responses yet

Dec 19 2011

Small Bites

I like keeping project tasks really, really short.  A week-long task is sometimes too long, but obviously satisfying when finished.  I also like keeping product releases very short.  A release might have only a few of these short tasks.  That ensures that the product is always within a few days of release.  Project scheduling is simpler when tasks are short.

No responses yet

Dec 15 2011

Predictive Analytics

Predictive analysis uses historical records to predict future trends or outcomes.  That got me thinking; could that be applied to timesheet records?  The most common field for predictive analysis is credit reporting, where lenders hope to predict a buyer’s ability to pay.

Do you have a 900 credit score?  Me neither…

So, back to timesheet data…  What could we possibly learn from predictive analysis of timesheet records?  Here are some possibilities:

  1. Cost and duration of certain projects in your portfolio
  2. Employee contributions to strategic projects
  3. Typical project contribution histogram overlaid on today’s projects

–newshirt

No responses yet

Dec 14 2011

Let’s do a meeting!

Published by raywhite under Advice

Does your company do too few meetings?  Yeah, you heard me right… too few.

If you’re like most corporate employees, you’ll answer, “Definitely not!”

Most of the scenes in the Dilbert comic are in meeting rooms.  That should tell you what Scott Adams thinks of them.  Meetings are the first signs of death in a once vibrant company.  But beware; lack of meetings may spell the same results.

Meetings done right should get your blood pumping for action.  You should go away wanting to try something new, or hoping for change, or at least inspired to follow.  Make that the aim of your next meeting!

No responses yet

Dec 13 2011

Project Documents

Published by warren under project management

A project manager has many things to administer…time, scope and cost, to name a few. These items are always considered in the very basics of project planning. It’s second nature.

What about managing all the various documents involved with project planning? Some software will accommodate document management, while many others do not.

It is important to have critical documents available to key resources, or all resources. Standard Time allows you to attach files to tasks. This makes related documents easy to locate and available for viewing when necessary. Many document management companies utilize Standard Time for their time tracking and project management. When considering project planning, make sure you have a solid software system that will help you be more efficient with document management.

No responses yet

Dec 12 2011

Timesheets are boring

Published by raywhite under Advice, Time tracking

Why get passionate about a boring timesheet tool?  They are little more than cells and dropdown choices that collect your time and expenses.  An endless bucket.  Pointless.  Employees reluctantly fill in those monotonous little cells every Friday afternoon or Monday morning for the week prior.  Time tracking is a chore with little value.

Okay, that’s one perspective…

But have you ever viewed them as an investment?  Like pouring value into your organization that you can mine later?  Consider that for a moment.

What if you could magically predict how long your next project would take?  Or cost?  What if you could walk into the next meeting with hard evidence that your company talents are unfocused and distracted?  That you are fighting too on many fronts?  And in too many battles without clear endpoints?  Wouldn’t that be worth documenting your time for.

That’s what time tracking gives you, among other things.  Still see it as a boring chore?

No responses yet

Dec 09 2011

Define: Percent Complete

Published by admin under Definitions

Percent Complete: The portion of a project task that has been finished.  Calculated by dividing the duration by the actual work.  In most cases, this the portion of the task with timesheet hours actually logged for.

Example: a 200-hour task with 50 hours logged is 25% complete.

No responses yet

Dec 08 2011

Why is it called ‘Waterfall?’

Warren has been expounding on project management methodologies lately, so I figured I’d throw in with him.  Consider this explanation of the ‘Waterfall project management model.’  It might be useful to some.

Here goes…

Why is the old project management model named ‘Waterfall?”  What, exactly, does that mean?

I believe the term stems from the notion that water falling over a dam is hard to scoop back up to the top.  Virtually impossible, one might argue.  The term ‘herding cats’ comes to mind.

So how does that apply to project management?

In real life, some projects are like that.  Not all, but some.  Consider building a skyscraper, for example.  You absolutely have to get that foundation right the first time, because you cannot go back and work on it after the ironworkers have laid a million tons of infrastructure on top of it.  In other words, reworking the foundation would be as hard as scooping up water that has already fallen over the Hoover Dam.
But are all projects like that?  How about software?

No.

Software is malleable.  You can work on any part at any time, even after the product ships.  So the Waterfall model doesn’t apply as neatly.  Or at all.  But it’s still applicable to certain projects where it’s hard to rework ‘foundational’ stages.

–newshirt

No responses yet

Dec 06 2011

Projects…Time…Projects…No Time

Published by warren under project management

Talk with many PM’s around the world and, no matter the project or project type, properly allocating time and resources is a never ending critical part of the job. Estimates based on the most solid metrics are subject to change and cost overruns. So goes the life of a project manager.
 
What’s surprising is how many PM’s don’t take advantage of the software tools available to them and deployed in their environment. Sure, most PM’s use the resource assignments, task dependencies and many of the software features available, but many do not put the simplest of task items into the software’s calculations such as the estimated task start and end dates.
 
I have seen tons of project plans that include the basics…task hierarchy, resource assignments, and maybe…the tasks start date. Why not use the tasks due/end date too? It takes a few extra seconds to enter and will help better identify resource overload and task delays. Standard Time has a resource allocation chart (pictured below).
 
 
 
 
Standard Time also displays the inverse, Resource Availability (also shown below).
 
 
 
 
I know a good number of PM’s utilize these tools properly, it’s to their advantage. But, many do not. I have seen it a hundred times. Aside from the obvious project idiosyncrasies, why not take a few seconds and save hundreds of minutes?

No responses yet

Dec 01 2011

Do you like Project Robots?

You just buried your mom and returned from the funeral. You’re a Project Manager on a high profile project for one of the largest tech companies in the world.  It has only been one day since the funeral and you are still raw with emotion.  Now imagine that you get an email informing you that you are not getting a break from the loss of your mom, but in fact, your workload has been increased.  How about a spouse fighting cancer?  Need a little time?  No!  Instead, how about an increased workload?  Sound crazy? Well, imagine no more…these are true stories.  This brings me to an important point.
In talking with a friend of mine with 26+ years of project management experience about Agile vs. Waterfall methods, he said, “You can have all the methods and processes you want but it all comes down to personal relationships and human intervention”.  This gentleman was responsible for one of the largest SAP installations in US history. I was taken aback by the simple answer when he stated another simple cliché, “Take care of your team and your team will take care of you”, which means that they will take care of the project.
The examples given in the beginning of this blog are not meant to say that we shouldn’t be tough or suck it up.  However, besides being in my opinion morally wrong, it is flat bad for business.  Is the man whom just buried his wife still ready to climb that mountain for the team?  Or, is he waiting for the first chance to jump ship?
All too often we pay lip service to our employees, “Let me know if you need any more resources”, while completely ignoring the realities of life.
I guess the bottom line is we can keep on pushing the machine, but what happens when the machine navigator gets ran over?  Does the machine keep going and if so, who is driving…a robot?
Make sure when you ask someone if they need help that you don’t ignore the reality that is staring you right in the face — unless you like robots.

One response so far

Nov 30 2011

My list of project risks

There are at least a hundred reasons projects fail.  Expect anything from vague requirements to budget shortages to waning passions to unreasonable project schedules.  All novice mistakes…  But we can’t all be experts on every topic.  About the best we can do is identify the most common areas for failure, and discuss these with the team.  At least the team will be aware.

Here’s a quick starter list.  You’ll probably have to make it a little more diplomatic before presenting it to your group.  “:)

1. Newbies don’t know how long things actually take.
2. Unfamiliar technologies need extra research time.
3. Virtual development teams don’t communicate the same as in-house.
4. Team members without a passion for the product won’t perform.
5. Vaguely defined projects either go on forever or burn up in debate.
6. Projects without top-level commitment get lost in the minutia.
7. If the company doesn’t need it bad enough, it will fail.
8. Pick only two: Cost, Quality, or Time.  Let the third fall where it may.

–newshirt

No responses yet

Nov 22 2011

Scrum Burn-down Charts

Published by warren under Agile Programming, How-to

In the world of project management there are often disputes over Waterfall vs. Agile methodology.  Most people have a bent or preference and there is plenty of discussion whether Agile can fit within any typical Waterfall project.  However there isn’t much disagreement among Agile proponents on the need for a good SCRUM chart.  Check out the link below from a recent blog posted on PMI.org by Bill Krebs.  Bill has an interesting take on Tracking Burn-down Progress…

http://blogs.pmi.org/blog/voices_on_project_management/2011/04/tracking-burn-down-progress.html

No responses yet

Nov 21 2011

Utilization Reports

Published by admin under Consulting, project management

In a Professional Services company, how do you know if you are billing enough hours to be profitable?  One way is to check to see if you’re still in business.  If so, you’re billing enough hours!

Okay, that works.  But wouldn’t it be nice to tune your billable hours for maximum efficiency?  That’s what a utilization report does for you.  It checks the number of hours for billable vs. non-billable.  the image below is a snapshot of one employee’s rates.  Not bad, huh?

Utilization Report

There’s an unofficial law at our company: Either find a way to bill 50 hours a week, or look for a job elsewhere.

That’s the hard reality at some companies.  You can bet management is watching the utilization reports.  Of course, if they don’t they’ll probably go out of business themselves.

–newshirt

No responses yet

Nov 18 2011

Time estimates are tricky

Published by newshirt under Advice

If you are an inexperienced project manager, engineer, or designer, consider tripling your initial time estimates for projects.  That’s not a slam.  It’s just that new managers don’t take a lot of minutia into consideration when developing project time estimates.  Experienced people have been through a lot of project cycles.  They have seen a lot, and the know the hundreds of little things that can bog a project down or extend it long beyond all normal estimates.  So if you’re new, triple the schedule until you know the details.

No responses yet

Jul 13 2009

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

By ExecutiveBrief -online resource on process management, project management, and process improvement.

No responses yet

May 28 2009

Success Factors in Knowledge Management

Knowledge management professionals must keep in mind that KM’s explicit end-goal is profitability while its implicit purpose is to empower participants through intellectual platforms and processes that promote learning and practical knowledge.

Knowledge, without a doubt, plays an important role in the success of any organization. In fact, in order to maintain a competitive advantage, modern organizations incorporate knowledge creation, knowledge sharing, and knowledge management into their business processes. The mere survival of many organizations hinges on the strength of their capabilities; moreover, companies form decisions based on their relevant knowledge of their business landscapes.

Thanks to developments in information and communication technologies, it is now easier to develop, store, and transfer knowledge. This capability is particularly true among organizations with global workforces. After all, international competition and globalization are the driving forces behind most technological innovations, and companies quickly take advantage of these developments when it comes to managing the creation and flow of information.

“Ultimately, leveraging relevant knowledge assets to improve organizational performance is what knowledge management is all about,” says Murray E. Jennex in his book, Knowledge Management in Modern Organizations (2007). However, in spite of the lightning-speed creation of new knowledge and the improvements in communication technologies, many organizations still find that their knowledge management practices are lacking. Specifically, within client-consultant relationships, knowledge transfer does not always translate into better performance by all project team members, nor does it always translate into the successful delivery of projects.

To be successful, knowledge management programs require more than simply conducting training sessions or transferring knowledge. Practitioners must always remember that KM’s explicit end-goal is profitability - while KM’s implicit purpose is to empower participants by providing them with the intellectual platforms and processes that promote learning and practical knowledge.

Here are a few factors that contribute to successful knowledge management initiatives:

  • Linkage between knowledge and economic performance – Knowledge management exists because it enables the organization to reach its business goals. Otherwise, there is no point in putting together all the best practices, tacit knowledge, and skill sets in a cohesive system that is accessible by all parties - when and where they need it. As business increasingly becomes more global, the competition for greater market share depends on the capabilities of its players to a certain degree. KM practitioners must be able to identify the business value of knowledge management in their organizations - whether it is to manage projects, provide back-office operations services or to give ideas on how processes can be better optimized - among others. In most consulting relationships, knowledge is the currency by which all transactions are made.
  • Setting and communicating clear objectives for specific organizational or project levels – Heather Kreech, the Director of Knowledge Communications of the International Institute for Sustainable Development has some specific ideas on this very subject. In her paper, Success Factors in Knowledge Management (2005), she states that knowledge-sharing works best when knowledge managers “gather and communicate knowledge at the project/activity/field level before [they] begin to aggregate up to corporate systems and general knowledge marketing strategies”. Having a specific organizational level or project group in mind, results in better designed knowledge management systems, training programs, and tools that can meet the specific needs of workers.
  • Having the appropriate systems and infrastructure – Ideally, knowledge is created, processed, stored, and archived. Managing the process of creating knowledge, communicating this knowledge to participants, and making knowledge available to anyone in the organization, means that an organization must have the right communication systems and data storage facilities. However, it is not enough to simply store knowledge as this knowledge must be found whenever it is needed. Thus, the availability of internal search facilities and computer-based training programs is critical.
  • Having the right champions – KM initiatives need project and process champions who can rally the support of everyone - from top management down to individual staff members. Having management support can result in the freeing up of resources - such as financial, expertise, and infrastructure - all of which are critical to the successful implementation of KM projects. Financial backing means that KM managers can implement training programs, hire both internal and external specialists - as well as acquire the required infrastructure to manage training programs. On the other hand, access to experts from either within or outside the organization, means better identification of knowledge gaps and training requirements, and more importantly, engineering training and communication programs that meet the said needs.

By ExecutiveBrief
Technology Management Resource for Business Leaders
http://www.executivebrief.com
¼/p>

No responses yet

May 14 2009

How to Create a Scrum Burn-Down Chart in Standard Time

Scrum burndown charts, or project history charts, as they are called in Standard Time help managers see the time remaining for projects in a line chart.  An example is shown below.  As many know, Standard Time is more than a timesheet.  It contains many project management features like task linking, resource allocation, earned value analysis, utilization percentages and rates.  These can be pretty boring topics unless you need to know where your project is headed.  And then they become pretty valuable tools all of a sudden.  Let’s take a look at the scrum chart.

 

Notice the falling line chart.  We’ll explain that shortly.

 

Scrum Burndown
Scrum Chart in Standard Time

The first step to creating this chart is to turn on project history.  Choose Tools, Projects and click a project to begin.  The project properties will display in the right-hand property panel.  Check the “Save task history” checkbox, as shown below.  This forces Standard Time to save time remaining for each project task when hours are entered into the timesheet.  Hours remaining are the raw ingredients for the scrum burndown chart above.

 


Save Task History in Standard Time
For Burn-down Chart

 

After turning on the “Save task history” option, now you’ll simply create project tasks and log time to them.  The image below shows a sample list of tasks.  Just remember that each task has a “Remaining” number of hours.  Those hours are plotted on a line graph in the scrum chart.  All tasks are combined to give a snapshot status of your project.  As you log daily time, those hours will fall, until they all reach zero.  Then the project is done!  You’ll see this gradual fall in the burndown chart.  Each week, you’ll notice trends developing.  Hopefully, going toward zero and completion.

 


Project Tasks in Standard Time

 

–newshirt

No responses yet

May 06 2009

Vicarious Goal Completion

Published by raywhite under Advice, project management

Bear with me…  Vicarious Goal Completion is a pretty obscure title, but there’s logic to it.  :)

Psychologists have observed a strange human peculiarity.  And it relates directly to project management.  It’s called Vicarious Goal Completion.  Researchers first encountered it while studying fast food menus.  Can I get you to bite?

When fast food menus contain a “Salad” choice or other healthy food items, people purchase the junk food instead! 

Here’s why: People who see healthy items on a menu feel good about their weight loss goals and give themselves permission to indulge a little.  So, they eat the burger and fries instead.  In other words, they remember eating good and believe they have already attained their goals, so that gives them permission to splurge.  The goals are completed vicariously through the menu itself.

Obviously, this is just a slick way of tricking oneself into dodging responsibility.  They used to call this laziness.  Any excuse to pig out.

I’ve notice the same behavior with software downloads and project tasks.  The ratio of downloads to form-completions is pitifully low.  In other words, people take the time to fill out a download form, but never actually install and test the software.  Vicarious Goal Completion!  The person believes they have finished the job, when in fact, they have only just begun.  Filling out the form gives them a warm fuzzy feeling about the goal of procuring software, and that warm feeling is enough to satisfy them.  They don’t actually care if they download, install, and test.  They have met their goals and that’s all that matters.

The same is true of project management.  Beware of employees who start tasks, but never complete them.  Once a task is started, good feelings arise.  Those good feelings give the employee permission of quit because they feel they have already finished, or full completion is within sight.  Vicarious Goal Completion!  Nobody likes to take their project tasks to the uttermost level of completion - unless forced to do so.

 

–ray

No responses yet

Next »