Wireless communication standards quietly changed around two years ago.  That’s when the draft standard for 802.11n became available allowing device makers to use it until the standard was released in 2009.  That standard – the full-fledged 802.11n – was released in September 2009. 
 
It was such a non-event because the draft standard really worked from the beginning with no real issues and great backwards compatibility.  Now that the standard has been fully ratified, what does that mean for companies that are still lagging a generation or two behind in their wireless communication setup?
While 802.11n is a lot faster than previous standards—it will transmit data at speeds of up to 160M bps over short distances—it offers other improvements, as well. These include a better method of encoding packets, making delivery more reliable; support for QOS (quality of service); and support for MIMO (multiple input, multiple output), which allows the radios in wireless devices to use multiple antennas to improve reception. Last but certainly not least, 802.11n devices operate on both the 5GHz and 2.4GHz bands.  And when using dual-band N access points this means is that B and G devices on your N network won’t slow things down…its win-win.  There’s no risk - everything will just work better as portions of your net- work move to 802.11n.

So, is it time to upgrade?  Other than cost, there’s very little to worry about…so the answer is basically YES.  Here are six things to consider when looking to upgrade your wireless networking to 802.11n:

·      You can just replace your existing access points with new ones when you upgrade your Wi-Fi. However, if you do so, you’re probably wasting money, since you almost certainly won’t need as many of them.

·      Even your old 802.11g clients will work fine, and their connections will be stable over longer ranges.

·      You have two frequency bands available for 802.11n: 2.4GHz and 5GHz. When possible, use the 5GHz range because there’s less interference on it, but the 2.4GHz and the 5GHz ranges are nearly the same.

·      When possible, use dual-band access points. You’ll gain significant flexibility and a lot more capacity.

·      802.11n supports things that older versions of Wi-Fi didn’t, including HDTV and streaming multimedia. However, you’ll get more benefit if you focus on capacity and reliability.

·      It’s perfectly safe to buy Wi-Fi products that say they meet the “Draft N” standard because those were certified along with the newer products that don’t have the word “draft” in them. However, steer clear of “pre-N” gear—it’s not certified and may not work with current wireless products.

I originally authored this article for the Real Deal Technologies website.

One of the most difficult tasks for many people in IT is providing estimates for project or development work.  However, it’s one of those necessary evils that must be performed – often at different times throughout the project.  There’s estimating done up front to price the project and scope out timeframes, there’s estimates for change orders throughout the project, and there’s often times ballpark estimates given to customers periodically on work they ‘may’ want performed.

I’m of the opinion that estimating is more of a gift – you either have it or you don’t.  It’s that ability to think somewhat abstractly on given tasks and figure out with some degree of accuracy what the level of effort will be.  Of course, there needs to be a certain level of experience and expertise – but that experience does not always ensure that you’ll give good estimates.  Over time, one can learn to be a good estimator, but it helps to have that gift.

With all that said, there are many things that can undermine the accuracy or validity of your estimates. Some you have control over and many that you can’t really control.  Here are nine common pitfalls that can often negatively impact project estimates:

Poorly defined scope of work. This can occur when the work is not broken down far enough or individual elements of work are misinterpreted.

Omissions.  Simply put, you forget something.

Rampant optimism. This is the rose-colored glasses syndrome, when the all-success scenario is used as the basis for the estimate.

Padding.  This is when the estimator (in this case almost always the task performer) includes a factor of safety without your knowledge, a cushion that ensures that he or she will meet or beat the estimate.

Failure to assess risk and uncertainty.  Neglecting or ignoring risk and uncertainty can result in estimates that are unrealistic.


Time pressure.  If someone comes up to you and says, “Give me a ballpark figure by the end of the day” and “Don’t worry, I won’t hold you to it,” look out! This almost always spells trouble.

The task performer and the estimator are at two different skill levels.  Since people work at different levels of efficiency, sometimes affecting time and cost for a task significantly, try to take into consideration who’s going to do the work.

External pressure.  Many project managers are given specific targets of cost, schedule, quality, or performance (and often more than one!). If you’re asked to meet unrealistic targets, you may not be able to fight it, but you should communicate what you believe is reasonably achievable.

Failure to involve task performers.  It’s ironic: an estimate developed without involving the task performer could be quite accurate, but that person may not feel compelled to meet the estimate, since “it’s your number, not mine,” so the estimate may appear wrong.

This article is based in part on information from Gary Heerken’s book “Project Management.”

I originally wrote this article for the PM Tips website.  The original post appears here.

The International CES - the world's largest consumer technology tradeshow.  And this year I'm going.  We'll, I guess it's next year, but it's only 104 days away according to the CES website.

Today my press pass/badge arrived along with all the free passes for lunches and events.  Living in Las Vegas as an IT consultant and author has it's perks at times - getting free passes to technology conferences as a press rep has been a nice perk so far in 2010.  So far I've been able to attend about $10k - $12k worth of conferences for free and I've gained lots of knowledge, article material, and freebies in the process.  My two 2-yr-olds love the light-up bouncy balls or anything that flashes for that matter!

The conference really begins for the press on 1/4 with CES Unveiled. Media, analysts and bloggers can get a pre-show look at who will be making news headlines at CES Unveiled. We get a sneak peek at International CES product debuts and the Innovations Design and Engineering Showcase honorees — before the show officially opens. 

On 1/5 is CES Press Day.  According to the CES website, Press Day is a MUST attend for CES media as major corporate, product and news announcements will be made. Press Day wraps up just in time for the preshow CES keynote address. 

I'm not sure how much I'll be able to attend, but I'm getting my press bag and taking in as much as possible.  Check back here in January for more information on CES as the show unfolds.

Managing the project budget sometimes seems like the most monumental task in the world, destined to take all of your time and still result in frustration and cost overrides.  However, it is one of the most critical tasks you can and will perform – right up there with ensuring proper requirements definition (and surprise, one can’t really be very successful without the other).

I’d like to discuss what I believe are four myths about managing project budgets and forecasts.

1.    Reporting project budget status to the customer will scare them.

When the project budget comes up as a discussion item with the customer, it’s usually not to give them good news.  That’s especially true if it’s not been something that was part of ongoing discussions or project status calls.  If it’s the first time you’re talking to the customer about the budget, it’s probably to tell them something is wrong. 

The budget and ongoing forecast updates are items that should be in front of the customer throughout the engagement.  If it’s good news, they’ll see that you’re managing the project well.  If it’s not such good news, they can help you and your project team make adjustments to try to get the project budget back on track.  And it’s always easier to fix budget issues if they’re not too far gone yet.  Keep the budget status in front of your delivery team and in front of the customer from the outset through deployment and you’re far more likely to remain within that acceptable +/- 10% range.

2.    If it’s a visible or mission critical project, the budget doesn’t matter.

Some project managers will go through a project thinking that since their particular project is critical for the customer or critical to their own company then budget doesn’t matter.  If it’s over budget and the customer HAS to have it, they’ll pay and they won’t care about budget status.  Or if it’s over budget and it’s critical to your own company, then your company will cover the overage.

That simply is not true.  There may be instances of that, but there’s no guarantee that any project is that important that budget won’t matter to the delivery organization or to the customer.  I once took over a trouble project where the client was a major government agency and I was led to believe that if it went over budget the agency would just request and receive more funding for the project.  It was well over budget when I acquired it and the bleeding never stopped – it just got worse. 

Eventually I – and my executive management – was blindsided when the government agency simply canceled the project.  This was after already spending more than $1.2 million on it and nearly 18 months of effort.  It can happen anywhere, anytime.  Surprise!

3.    All the eyes in the world can’t keep an out of control budget in line.

I am a firm believer that there are bleeding budgets out there that, given the proper management and oversight, can come back in line – at least to some sort of acceptable point.  The issue is to stop the bleeding.  When you figure out why the money is pouring out the door and halt it – and it may take a temporary work stoppage to do it – then it’s easier to wrap good budget management practices around it.  And a well-tracked budget is much easier to diagnose and fix then one where the checks are just flying with no accountability.

As the PM, if you’re taking over a project that is out of control or even if you’ve let one get out of control due to lack of oversight, stop where you are and prepare to take drastic action.  Freeze expenses immediately, forecast weekly all expenses (based mainly on forecasted resources hours and their associated rates, usually from the project schedule), track those weekly using actuals against forecast, and dutifully report that information to your project team, your executive management and the customer on a weekly basis. 

You may never get the budget fully back on track, but your extreme oversight will likely keep it from getting any worse and will be very appreciated by both the customer and your organization.

4.    Project team members charge their time accurately.

We stock our projects with skilled and highly trained professional resources.  We expect them to be accurate with their work and we expect them to be accurate in how they charge their time.  The truth is, very few of us actually meticulously track our time during any given week – we usually throw our timesheets together at the 11th hour because we’re busy with real work.  News flash – that’s what our project team members are doing, too. 

Just like the PMs, these team resources are working multiple projects at a time.  What’s different about your team members – the BAs, the tech leads, the data specialist, etc. – is that they aren’t responsible for the project budget…they just have to charge to it.  As the PM,  you must make them aware of the project budget and the ongoing forecast on a regular basis.  If they know you’re tracking it closely and they know how much time they’re supposed to be charging to the project, then that’s what they’ll charge. 

Pity the project manager who isn’t tracking their project budget, because that is where the ‘grey’ hours go.  That’s those 5-6 hours every week that you simply can’t account for but you know you worked them so you have to charge them somewhere.  Your project team members will charge them to whatever project’s budget isn’t being watched closely.  Make sure that’s not your project.

I originally authored this article for the Projects@Work website - the original post appears here.

The title basically says it all. We go to school, we go to training classes, we join associations, we read books. We do everything good little IT and business people should do to better ourselves in our profession. And, at the end of the day, we’ve learned some things that help us in our jobs.

But what do we really learn the most from? Growing up, did you learn more from what you were told to do or did you learn more from what you did wrong and had to pay the consequences for? I contend that the latter wins hands-down. It’s nice to learn things…it always is. But when we screw up really good and pay some sort of price for it…I contend that those are the times that we really really LEARN.

Example #1

Case in point…. I’ve mentioned many times how budgeting issues can torpedo projects and I’ve had at least one major project of mine go south due to budget handling issues. I’ve passed blame somewhat, but overall I’m the Project Manager and that’s my responsibility. That which does not kill us makes us stronger, right? I firmly believe that. And that which does not get us fired makes us a better employee, a better server of our customer, a better business professional.

One major project completely shutdown for budget issues that could have been avoided – or least the blow could have been softened – with the appropriate action. I learned from that mistake and budget information is key to weekly discussions and project status reports that I have with and share with the customer now. It’s formally documented – both current budget and forecasted budget – and discussed formally every week. I’ve taken away the question marks and made it a joint effort with the customer. And believe me, the customer always appreciates the knowledge and would rather know the bad things and work through them with you then to waste money and cancel an engagement. I’m certain of that.

Example #2

I also worked on a major $50 million program for the US Department of Education. It was much more of a program than a project – it had a five-year run followed by an RFP process and our proposal and another contract win. The company I worked for always won it because the program had grown to such a large size, it was so complex and had so many add-ons that no potential bidder could knock us – the incumbent – out of contention for the next proposal. We had become fat and overconfident.

Then one day a funny thing happened. We missed a major milestone deliverable. Then we missed another. Then we improperly tested a change order resulting in delays and re-work. Suddenly, the government was not so enamored with our performance and certainly had lost confidence in our ability to deliver. We desperately needed to learn from this mistake, act aggressively and right the ship before it was too late – because at this point the project was within one year of coming up for re-bid.

I had responsibility on this program for all financials and budgeting, all change management, all change orders, disaster recovery, and status reporting. Production was not in my scope, but I pulled my direct reports together and we resurrected the project schedule that I had put together 3 years prior in order to win the current contract and we updated it to what was happening today. What my team and I turned out was a project schedule encompassing nearly 4,000 tasks and a my peer managers on the program were ready, willing and equipped to manage their specific portions of this mammoth project schedule.

My responsibility was to bring that all together and take over leading the weekly status meetings with the government managing everything to that schedule and producing meaningful alert reports from it both for internal purposes and for the customer to hold us accountable to. What resulted was a project that quickly got back on track, a customer whose satisfaction was raised beyond the level it had been previously and another huge contract win down the road. It wasn’t my doing – my entire team and I took the initial action – but everyone pulled together and made it work. We learned from our overconfidence and mistakes before it was too late. And in this case too late could have meant losing our jobs in a year if the contract was lost.

Summary

We’re human…we’re told what to do from the time we’re born till the time we die from someone or another. It doesn’t matter if we’re John Doe or Donald Trump…someone somewhere is instructing us off and on. We learn from those instructions. But I believe we also learn very fast – maybe faster – when we screw up and suffer the consequences. Sometimes we have to fail to perform better.

I originally authored this article for the PM Tips website - the original post appears here.

What does it take to setup project management for a startup?  That all depends on the startup, the size of the startup, and possibly even the industry.  I’d like to say that PM is the same across industries, organizations, and organization size, but it’s not.  I’d like to say that PM practices need to be the same across all organizations regardless of their undertakings and project sizes, but that’s not necessarily the case.

Flex with the Need

I subscribe to the concept that PM practices are basically the same, but need to be ‘flexed’ to fit the organization, the need, the size of the project, etc.  But it still needs to happen.  Given that – assuming we agree on that for the moment – then what about the startup?  Does it need project management to see it through it’s first few customers or it’s first few internal revisions of it’s product offering?  Is it really necessary if the startup only has, say, 12 employees?  Yes!

The principles – the true needs of the organization to get a handle on what’s happening with the work they are doing – are still there.  The need to satisfy an external customer or produce a solid product so that there will still be paying customers out there waiting is still there.  The need to adequately manage the cost/budget, the resources, and the timeframe that is required to get the work done is still there.  And if that need is there, so is the need to report on those items – whether that’s a formal reporting to an external entity or a more informal reporting to a small team internally….the need for tracking and accountability is there. 

Poor Practice begets Poor Practice

It will always be there.  And if it is ignored, it will always cause problems.  As I’ve said before, you can sometimes get lucky and skate through on a very small undertaking or project.  But that can’t last and as your organization grows so do your projects and your customers and your staff size.  Those practices that got you to where you are will likely continue to be followed.  Poor practices and loose tracking early on will lead to poor practices and loose tracking later on and when your organization, projects and customers are large enough…and that won’t take long…then you’ll begin to experience the major issues that accompany disorganized project management and accountability.

Do it Right Early

What I’m trying to say – and what I’ve worked hard to instill in the startups that I’ve worked with -  is this….do it right NOW, and it will always be right.  Good practice will lead to growth, growth to profitability, profitability to more growth, more customers and more satisfaction for customers and your staff.  Avoid the frustrations that many startups go through by ignoring this concept in their early stages.

I’ve mentioned this before…one startup called me in to help them through the process of bringing their first three customers ‘live’ with their product offering.  They lacked any true project management oversight and the customers had lost all confidence as the revised go-live dates kept coming and going with no end in sight.  It wasn’t until I got them to step back, setup proper processes and tracking, and got the customers’ buy-in to the new processes that we were able to get those customers live and eventually push the startup organization over the line to profitability. 

Do it right early, setup processes that can grow with the organization, and many of those frustrations that arise trying to manage critical projects for a new startup will simply not occur.


I originally authored this article for the PM Tips website - the original post can be viewed here.