Hylton's Blog

Dealing with Unethical Project Clients

2012-02-08T12:59:00.000-08:00

There’s no question that we are in the IT consulting business to make money, right? We can’t feed our family on fun and professional growth. The dollars must keep coming in – otherwise we have to start looking for something else to do.

Given that, the thought of turning down business is a hard thing to fathom – especially in this economic climate. Recovery?? We’re truly not there yet. It could be years...who knows? So, in the mean time we all struggle to remain viable while trying to pick and choose our projects and our clients – if we have that luxury – to the best of our ability. We try to only take on customers who seem reasonable, ethical, and won’t drive us insane. Does this sound familiar to you?

Hooking up with the client

Through whatever process you choose, you’ve hooked up with a potential client. It may be a situation where they found you from a professional article or professional posting or possibly you found them when you contacted their organization offering your services. Or even better, maybe they found you through a referenceable customer of yours. However it happened, it happened. And now you’re face-to-face with this potential client discussing their needs, high-level requirements and business processes and trying to determine three things: 1) is this work I can do, 2) is this a project I want to take on, and 3) is this a client I want to work with. You may have even started to draft out a project plan with your online project management software tool at this point. #1 is should be fairly easy for you to answer after a brief discussion with the potential client. The harder questions to answer are #2 and #3. You don’t know much about their business and their employees yet and you don’t know much about your direct customer contact. You have no idea if they are going to be easy to work with or difficult to manage. And you can’t determine really at this point if they are ethical or unethical.

I will say this – if you have a gut feeling early on that they may be unethical or you feel uncomfortable with them…don’t move forward. I can attest to the fact that, without exception, every time I’ve had a discomfort level with a client or even a direct employer and then moved forward with them anyway, I’ve been sorry.

You’ve made the wrong choice

There will be times when you determine that you’ve made the wrong choice. You’ve decided to move forward with a client who is or is going to cause you lots of headaches. You’ve had to add so much planning and other extra time into your web-based project management software tool just to accommodate them and their headaches. They may be unethical. They may refuse to pay for services rendered even though you’ve delivered good work. They may continually try to push scope but balk at paying more. They may call you at all hours of the day and night. Whatever the problem or frustration, you’ve realized you made a poor decision to work with them.

I had one client who I had misgivings about early on. The reason why I decided to move forward with the work is mostly due to the fact that I had maintained a relationship with this potential customer for six months trying to get to the point where they needed my consulting. When it finally happened, I ignored all of my misgivings and moved ahead. Bad call. They brought in clients and lied to them. They took them out partying and then discussed the lurid details during face-to-face client sessions with them. Too much Las Vegas fun, not enough professional work – and that’s not my style. And in the end, they abruptly ended the consulting engagement owing me over $2,000 in consulting fees. Unethical? Yes. Stupid decision on my part? Yes….I take full responsibility.

The exit strategy

So, if you find yourself in a bad client situation, what do you do? My recommendation, in order to not start bad word of mouth about your services, is to not end anything abruptly. Look for an out – possibly a key deliverable coming up or the end of a phase or milestone in the project management software schedule. At that point, make sure you’re paid up to date, and then break it to the customer that you have another pressing engagement and you can’t move forward any further on the project.
Of course, you must first ensure that you’re not breaking something in the contract that may leave you facing legal action. If that’s the case you’ll have no choice but to continue with the project. But if you can find and out, take it. And to leave things on the best grounds possible, suggest another consulting contact as a possible replacement – even if they may be remotely located in another part of the country. At least you’ll go out offering a solution.

About the author:

Brad Egeland

Brad Egeland is an IT/Project Management consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is a married, Christian father of 7 living in Las Vegas, NV. Visit Brad's site at http://www.bradegeland.com/.

Are You Sure Your Project Information is Secure?

2012-02-08T12:48:00.000-08:00

Fellow blogger V. Srivinasa Rao recently wrote an interesting post about the Global Distribution Model 2.0 that is launching soon. The model holds a lot of promise and is a great framework for implementing mobile global communications tools.

Today, the fastest rising communications and computing technology is mobile. And while this development provides exciting possibilities for improved project efficiency, it does not come without risks. I'm focusing specifically on devices with a mobile operating system, such as iOS, Android, Windows Phone 7, Blackberry or Nokia.

The reason for my concern is the speed of adoption for the devices. They now play a role in every project I manage. It may be simple communications such as email between team members, text messaging and calendar functionality, or more sophisticated uses such as remote access to project data, project management software or even video conferencing. Yet 90 percent of the time, I find that no one is really thinking through the implications of using this technology.

Think about it: With this expanded communication comes an increased risk that your project's confidential or critical information could be exposed, intentionally or unintentionally.

This information can be controlled fairly easily by IT departments on laptops, but mobile operating systems don't allow for the same kind of security just yet. You must be wary of how information may be getting communicated over your mobile device.

Information "attacks" can come in several forms. At an event where "free wireless access" is offered, for example, someone who wants to gather data illegally can set up a US$50 wireless router, name it "[Event Name] Wireless" and watch as attendees innocently connect their devices to communicate with the rest of the team. Simply leaving your Bluetooth enabled in public locations can open you up to attacks.

It doesn't even need to be something that devious. All that needs to happen is for one of your team members to lose a device that has regulated data on it. In the United States, you'll have to officially report the incident to the Federal Government.

The key takeaway here is that as our world expands, we are being given exciting new ways to coordinate and communicate with our team members across the planet. We should take full advantage of this. But we should do it with our eyes open.

Article by Geoff Mattie for Voices on Project Management

6 Tips to Persuade Stakeholders to Say "Yes" to Your Project

2012-02-08T12:32:00.000-08:00

Sourcing project acceptance and buy-in from stakeholders is a challenge. The article below by Jorge Valdes Gaciatorres hightlights useful hints to employ. I would add awareness of all the cultural elements when selling a project to stakeholders, is imperative. Getting to know the prospective stakeholders is very important. It will help to stay away from embarrassing comments that may fuel discomfort amongst stakeholders. On the other hand, it may yield immense goodwill from members that lacked certainty to become involved in your project.

Jorge Valdes Gaciatorres writes in Voices on Project Management:

Starting a project is not always easy. It requires resources and changes the status quo, so there can be a lot of obstacles until you hear "yes" to a project.

That's why you need to know how to effectively persuade your stakeholders to get on board with your project.

Dr. Alan H. Monroe's motivated sequence pattern, created in the 1930s, is useful for doing so:

1. Attention: Capture your stakeholders' attention with an interesting opening statement, or share a statistic related to your project.

2. Need: Identify the need that your project will address and share it with your stakeholders. The more information you have about the business needs, the better the chance your project is approved.

3. Satisfaction: Let stakeholders know how your project will satisfy the identified business needs. In detail, describe the approach you'll use in your project to address the needs.

4. Visualize: Explain the 'perfect world' that will exist after the project has finished. Make it as vivid as possible -- explain how it looks, sounds and smells. Be very energetic and enthusiastic when you explain.

5. Action: Tell them what you need them to do. Let them know specifically what steps you are taking to achieve the vision you've just shared.

The sixth element I would add is to tell a story to help you make your point. It could be real or it could be fictional, but remember that people are more likely persuaded when they hear or read a story that transports them. If a story is told well, we get swept up and are less likely to notice things that don't match up with our everyday experiences.

Use your creativity -- find your own way to mix all of these elements and you can build a powerful tool to persuade even the most demanding stakeholder.

Bad for Business: 4 Poor Facebook Habits

2012-01-23T19:15:00.000-08:00

If you don't have a Facebook page for your business, it's not the equivalent of trying to operate without a telephone and modern plumbing. But social media is something almost no business can afford to be without.

Social media allows a business to connect directly with its consumer base. A business with a Facebook page is approachable, personal and accessible.

Before the advent of Facebook, businesses relied on press releases and advertising to get the word out about sales or product developments that might interest customers. Compiling those took time and money. But the amount of information a company can disseminate now is constrained only by the number of times the person in charge of social media can hit the Post button.

The ease of disseminating information, coupled with a general lack of Facebook etiquette, can become a problem in its own right. And some common social media behavior can have serious negative repercussions. Below are four offenses business pages commonly commit.

1. Overposting

Because the only constraint to posting on a business Facebook page is the willingness and stamina of the poster, many businesses try to break their own posting records every day. Every thought the poster thinks is deemed essential public knowledge, and it's shouted from the Facebook rooftops with gusto.

Overposting clogs up users' newsfeeds. Your business’s postings become white noise and an annoyance. Then, they become spam.

When customers feel that your page has spammed them, they will either hide your business from their feed or delete you from their list. And once they delete you, the follower is unlikely to reverse their decision.

How much is too much? If you're posting more than once or twice a day, you risk alienating your customers.

2. Oversharing

Oversharing is not overposting, which is talking too much. Oversharing may be treating the business’ Facebook page like your diary or your political soapbox. Treating your company’s social media page as anything except a PR platform is oversharing.

It's fine if you want to inject a little personality into your promotion platform. But there’s a fine line between "personality" and "personality crisis," and once you cross the line, your page is toast. People will hit the "Hide postings from…" button faster than you can say "Ron Paul Forever!!!" (Oh, and turn the caps lock off.)

3. Poor writing

Many businesses cut a corner by writing their own social media content tor farming it out to an intern with poor grammatical skills. Your Facebook feed come across like the the local furniture-store owner who does his own TV commercials. Unless that’s the aesthetic you’re going for, consider having somebody professional look it over.

And by professional, we don’t mean your text-speak-fluent "resident young person." Bad writing (multiple misspellings, clunky prose, the overuse of emoticons and abbreviations) makes your Facebook page look unprofessional. How many people want to patronize a business projecting a voice that says essentially, "Uh, yeah, whatever"?

4. Lack of moderation

Your Facebook Wall is like your community bulletin board. So, it will probably collect graffiti. Personal musings, links to dubious sites, pictures of somebody in a swimsuit—whatever it is, random crud will clutter up your page. You have to be diligent to keep your Facebook page spic-and-span. Otherwise, you risk having a page where law has no name.

While you don’t need to put a full-time hall monitor on your page, you have to clean things up once in awhile and delete postings that don’t fit the purpose of your Facebook page.

Article by Jacob Harper for Open Forum.

More about the author:
Jacob Harper co-founded the Vintage Vice clothing store and apparel brand in 2006 when he was 23. He sold Vintage Vice in 2009 and now works as a teacher and writer. He is currently a writer for the weekly political sketch show Top Story! Weekly at the iO West in Hollywood.

How Social Media Changes Technical Communication

2012-01-07T20:09:00.000-08:00

Technology journalism is not so different from that other brand of technical communication in the sense that we both aim to make complicated information clear. My wife is an STC member from a couple of past gigs at software companies and some more recent consulting work, and I've occasionally done documentation and technical marketing writing. I also maintain a couple of WordPress plugins, which are documented in a series of blog posts that I have to revise on a regular basis because people complain when my explanations are unclear.

The Web in general has democratized the world of publishing, and social media only more so. Professional communicators must work harder because they're now in competition for attention with the voice of the crowd, blurring the distinction between author and audience. As a journalist, I can be excited about the dynamics of blogs and social media sites but still worry about them siphoning off of ad dollars from professional publications. Similarly, STC members must wonder whether it's to their advantage to organize documentation in a wiki that anyone can add to or edit.

On the other hand, denial is not a great strategy. The challenge for the professional communicator is to contribute at a higher level, welcoming community involvement and building on it. For the technical writer, that may mean doing less writing and more curating of content--for example, identifying and promoting the best wiki contributions, correcting errors, clarifying unclear language, adding illustrations, and improving organization.

"Tech writers have been humanists who ended up in the tech world and have been part of R&D, with their work thought of until fairly recently as part of the product release cycle," Schwartz told me a few months ago. But documentation no longer just gets stuffed in a box and shipped. Now that much of it is available online, it's become common for people to read the documentation before they buy the product--making it more important than ever to have clear documentation that makes a product inviting rather than intimidating.

Article by David Carr for Informationweek:
Follow David F. Carr on Twitter @davidfcarr.

Read full article at:
http://www.informationweek.com/thebrainyard/news

4 Pillars Of LinkedIn Marketing For Businesses

2012-01-04T23:34:00.000-08:00

With more than 134 million members, LinkedIn has changed the way employees and employers connect – and how professionals and businesses find partners.
Anyone building a business (online or offline) should take a close look at how this powerful network can work for their business.

LinkedIn is a very simple platform. People, in large majority, use the site for job searching. And because of this most LinkedIn users are not active as often as those on Facebook or Twitter. However, there are niche opportunities that many businesses can take advantage of and should make sure they are considering.

Here are the 4 cornerstones to using LinkedIn for your marketing. Make sure you are not missing out on an opportunity.

1. LinkedIn Groups

This is the favorite LinkedIn activity amongst heavy users, yet while savvy businesses recognize that creating a LinkedIn group gives you the ability to generate (hundreds and thousands of) leads, they understand this is only the first step on the long journey to success.
When creating a group on LinkedIn for business purposes, your goal is to create a group that holds value for the audience first. A few tips:

Look for a niche topic in your industry. Look at pain points that your customers have a lot or growth areas of your business and focus there.
Name the group for the niche and not for your business name. This helps search and helps guide the group toward audience value and not the business goals.
Make the group open so that it can grow more easily.
Promote the group to your existing channels.
Target existing brand champions and passionate fans and ask them to stop in once a week to help promote discussions.
Have a plan for maintaining activity in the LinkedIn group. How often will you or other employees promote discussions? What messages are allowed and how often will you moderate group posts?
Use the best discussions and reoccurring questions as inspiration for blog posts and new products/services.

2. LinkedIn Answers

Similar to Yahoo Answers, this professional network has a Q&A section, available for users to post (niche-related) questions to their network, inviting connections and other users to answer. LinkedIn answers is the largest professional based Q&A site out there. Recent trendy Q&A site Quora is another good direction for this type of networking, but LinkedIn certainly still has some street cred when it comes to business networking.

When you take advantage of this option and actively participate inside on a weekly or daily basis, you start to naturally build your credibility by connecting with new professionals and top experts in your industry. Some tips for using LinkedIn Answers.

Have a schedule and interact regularly, either weekly or daily
Pick a handful of topics to focus on and become a heavy hitter in these sections of the site
Provide overly useful answers, pointing to many resources. The more helpful you are the more attention you will get from potential business partners and customers.
If you are acting as a company, use multiple people to support each other in discussion in a show of force. There is not need to game the system and just comment with “attaboys” and “I agree”. But having multiple employees with smart helpful discussion can only help your cause.
Make sure you don’t go into sell mode and overwhelm other users by pushing your product constantly or aggressively.
Again, look for opportunities to reuse your answers and discussions as blog posts to keep the thought leadership going.

3. LinkedIn Events

This is a fantastic way to engage with your clients and leads online, or offline. Here you can post your events, with a short compelling description about each, and a link to the registration page.
Towards the end of 2011, LinkedIn overhauled their events application and made it much more use friendly and much more useful to businesses. Attendees to events can connect more easily with one another. And event search is better making it easier for you to get your event in front of new eyeballs.

A few LinkedIn Event tips:

Use events for more occasions. If you have a sale on your product coming up for black friday, make an event people
Fill out everything, including: Full and descriptive event title, avatar, short powerful description, times, location, and registration link.
Link the event to your LinkedIn company page
Direct all potential attendees to click on the “I’m Attending”. Each time someone is added, it gives you more chances to show in their timeline and for their friends to be influenced to find out more about your event.
Setup the event early in the your planning process to get all volunteers, speakers, partners, participants active as “attending” to make the event look as popular as possible.
Promote your event through LinkedIn Groups
Promote your event through LinkedIn Ads

4. LinkedIn Advertising

Imagine how it would feel like to be able to tap into specific audiences like for example 1.3M small business owners, 12M small business professionals or 2M C-Level execs, and have total control over your advertising budget, by only paying when someone clicks or views your ad.

LinkedIn calculates a quality score for your ads, similar to Google AdWords, but only uses your all-time CTR (click through rate) and your bid. LinkedIn ads have far fewer options than Google or Facebook ads but can still be a great performer.
Your text-ad will appear at the top, right under LinkedIn navigational menu, and/or on the right sidebar with your logo, next to it.

A few tips for LinkedIn ads:

Your headline will be 25 characters in length while your description 75, meaning what you say should be concise & compelling.
Target, target, target. Just as with Facebook ads, targeting your audience is one of the most important aspects of your ad, as well as one of the largest benefits. Use the filters available.
You can advertise LinkedIn groups, events, company pages, and profiles. As well as outside URLS.
Split testing is easy with LinkedIn Ads so setup groups of ads to test performance on your copy, your targeting, and your images. Your minimum daily spend on LinkedIn Ads is only $10 so it is very affordable to test.
Social networking ads see user fatigue often. Pay attention to performance declining. You may have to change out your ad creative weekly to maintain performance.

About the author:

Jason Keath is the founder of Social Fresh, a social media education company. He is a social media speaker and analyst. He also consults with corporations and agencies on building community and influencer outreach. Follow Jason on Twitter @jasonkeath

How to Land a New Job in 2012

2011-12-30T10:53:00.000-08:00

Whether it's rewriting your cover letter, reviewing the way you approach interviews, or rethinking what kind of job will make you happy, here are some tips for landing a new job in the new year. You'll hear from authors, career experts, career coaches, and even entrepreneurs.

Position yourself as a thought leader in your industry. Create a professional blog and write insightful posts about industry trends and advice. Comment on other top blogs to increase your visibility within those communities. Join and participate in niche communities, such as LinkedIn groups related to your expertise and skills. Share relevant articles (and your own content) on Twitter, Facebook, and Google+. Not only will this help to develop your online presence, but you'll inadvertently network with people who might lead you to your next job opportunity.

Heather R. Huhman is a career expert, experienced hiring manager, and founder & president of Come Recommended, a content marketing consultancy for organizations with products that target job seekers and employers.

Let a job find you. If you are a job seeker, you need to shift your focus. Instead of spending all of your time identifying jobs and applying, you should also think about how to help people who want to hire you, find you. Ramp up your networking efforts. A Jobvite study showed 89 percent of U.S. companies will use social networks for recruiting in 2012 and 73 percent of social hires are via LinkedIn. In its job-seeker survey, Jobvite found 78 percent of job seekers who credited their current job to social networking named Facebook as the key factor in landing their position and 42 percent mentioned Twitter. Ignore any of these key social networks at your own risk.

Miriam Salpeter is a job search and social media consultant, career coach, author, speaker, resume writer, and owner of Keppie Careers.

Write a new cover letter. If you're still using a generic cover letter that simply summarizes your resume, you're missing out on one of the most effective ways to get an employer's attention. In 2012, throw out that old letter and start writing new ones for each job for which you apply. In this job market, you can't afford to squander an entire application page repeating what's on your resume. Instead, use your cover letter to provide information about how you're fit for the job; information that isn't available on your resume, such as personal traits, work habits, and why you're excited about the position. For instance, if you're applying for an accounting job that requires top-notch organizational skills, and you're so neurotically organized that you color-code your bills every month, most hiring managers would love to know that about you. And that's not something you'd ever put in your resume, but the cover letter is a perfect place for it.

Alison Green writes the popular Ask a Manager blog where she dispenses advice on career, job search, and management issues.

Bring questions to a job interview. When an interviewer asks you if you have any questions, make sure you do. And make sure they're good ones. Having smart questions will show an interviewer that you are discerning about the company for which you work, that you have prepared for the interview, and that you're familiar with the company. Spend some time looking at company reviews online and reading the latest news about the company and about the industry overall. Possible question topics include: corporate culture, organizational structure, day-to-day responsibilities of the position, the company's standing in the industry, and the company's five-year plan.

Luke Roney is content manager for CareerBliss, an online career community dedicated to helping people find happiness in the workplace.

Follow up after an interview. If you are genuinely interested in the job after the interview, make a habit of sending a follow-up note of appreciation. While a thank-you note doesn't guarantee you'll get the job, it certainly won't hurt you. Not only is it a gesture of common courtesy, it's a perfect place for you to reiterate your interest and show the hiring manager why you are the right person for the job. It also gives you the chance to add a detail about your background that you may have not had the opportunity to explain in the interview or to just simply reinforce the connection. Sending a follow-up note via email is acceptable and quick, however, a hand-written note will set you apart from the competition.

Lindsay Olson is a founding partner and public relations recruiter with Paradigm Staffing and Hoojobs, a niche job board for public relations, communications and social media jobs.

Create your own business. When you look at the history of business over the last 100 years, you will find that many of today's most successful companies started in the 1930s—the same decade as the Great Depression. The fact is, innovation and business growth comes out of downed economies because entrepreneurs are problem solvers (and there are certainly enough problems to be solved in times such as these). We are in the age of the entrepreneur. The new economy has forever changed the social norms of yesteryear, so 2012 is as good a time as any to join the entrepreneurial revolution. So break free of the resume life, start something small that can grow organically with hard work and undying passion, and make it in this world on your own.

Scott Gerber is the founder of the Young Entrepreneur Council and co-founder of Gen Y Capital Partners.

Article by Ben Baden for Money Careers.

What is cloud computing and is it right for me?

2011-12-28T23:05:00.000-08:00

The term “cloud computing” is everywhere these days. It’s not a new phenomenon, but rather it is continuing to evolve.

The simplest, nontechnical definition of cloud computing is using an Internet browser to access software applications over the Internet. People who use Facebook, LinkedIn, Salesforce.com or free email services are using a form of cloud computing.

The recent surge in popularity in cloud computing is driven by the fact that businesses do not need to make a large capital investment in servers or licensing fees. In other words, the future of computing becomes subscription-based, and not ownership-based.
Like any type of business evaluation, the simplicity of subscribing to computer services has both advantages and disadvantages. Cloud computing for contractors can range from easy to complicated, depending on numerous variables.

The important thing to consider has nothing to do with technology. Instead, the starting point in the evaluation begins with how a firm conducts business operations. Companies can embrace cloud computing by understanding the five major components surrounding cloud-based technology. Those are:

1. Operational/functional standards
Every contractor has both standard business needs and unique operational functions. For example, we all need standard business functions such as email, invoicing, check writing and general ledger activity. That’s the simple part.

But we all have more customized operations that might include quoting, timekeeping or unique reporting standards such as “board foot,” “gallons per minute” or “percent of completion.” One additional function for contractors to think about is mobility and how cloud computing will impact secure access to data in the field.

In other words, data is no longer in the office. It is sitting somewhere out in the “cloud.” How a contractor accesses, manages and utilizes that data will become the key in deciding when and how to use cloud computing in the business.

The important issue to understand before moving to the cloud is whether those established functions might change or even be eliminated. Moving to the cloud without conducting enough due diligence may result in a loss of control within the organization.

2. Cost
Most cloud computing solutions have a monthly subscription fee. That’s a huge advantage, because contractors no longer face large capital expenditures for hardware, software or licensing fees.

However, there may be hidden costs that are not obvious. Those costs could range from something as simple as data retrieval to something more significant like purchasing additional bandwidth to handle increased Internet traffic. Most information technology professionals agree that cloud computing will not be cheaper in the long run.

3. Security
A company’s most valuable business asset is its data. All of that data – such as invoices, drawings, spreadsheets, proposals, customer lists or email correspondence – is a critical, ongoing concern.
Admittedly, there are security risks when the infrastructure and data are managed in-house. But once that data is moved into the cloud, companies expose themselves to different forms of security risk.

Companies need to consider an entirely different approach to data security. If a firm deals with government agencies or HIPAA customers, this will add an even greater level of concern.
Knowing who has the keys to the kingdom is an important consideration when evaluating cloud solutions. It requires careful attention to make sure data does not end up in the wrong hands or subjected to a higher risk of hacker attacks or virus infections.

4. Service
When managers think of customer service, they might compare cloud-based solutions to “self-service” environments. That means service may be lower than the company needs.

Even as cloud solutions improve in speed and reliability, customer service will always be needed. It would be unrealistic to believe that cloud-based computing will eliminate end-user incidents or questions. Help desk issues will more than likely still exist after a shift to the cloud.

Understanding the level of service provided by vendors will be important. An IT adviser can help determine whether customer-service levels will be satisfactory.

5. Timeline
Time can change everything. There will be changes in cloud computing. Hopefully, risks will be mitigated and service levels will improve. But no one knows for sure how this trend will unfold.
The act of moving data and operations to the cloud does not need to be rushed, especially if investments have been made already in servers and licensing.

The best way to think about cloud computing is in the same way as a purchase of a large piece of business equipment. That usually begins with evaluating viable equipment, the features and benefits different vendors offer and what best suits operations.

Fortunately, there are qualified IT professionals who can help guide companies in the selection of a technology vendor that can match their operational needs. Technology is a tool that serves the contractor.

About the author:
David Murray is CEO of Convergence Networks. Contact him at 503-906-1539 or at dmurray@convergencenetworks.com

Avoid Conflict with Your Project Sponsor

2011-12-28T22:55:00.000-08:00

Advance your career by engaging — and not enraging — project sponsors.

Project sponsors provide financial and political support — but they might not always know the day-to-day details of how an initiative is faring.

A key role of project managers is to monitor constraints. More often than not, they know better than anyone what’s best for the project.

To minimize conflict (and the negative effects on their career), project managers should define their roles and responsibilities at the outset. It must be clear who is responsible for making what decisions.

“Projects resemble an hourglass,” says David West, senior technical director at WSP Group, an engineering consultancy in London, England, and author of Project Sponsorship: An Essential Guide for Those Sponsoring Projects Within Their Organizations.

“The bottom half of the hourglass is the project team of consultants, designers and contractors who will deliver the project,” he explains.

“The top half of the hourglass is the organization investing in the project and all the parts of the organization that will be affected by or influence the project. At the neck of the hourglass, back to back, stand the project sponsor and project manager, the sponsor managing the top half and the project manager running the bottom half.”

Speak the sponsor’s language, suggests Kiron D. Bondale, PMP, director of the corporate project management office at Agricorp in Guelph, Ontario, Canada.

“Sponsors may not be project management specialists, so it behooves the project manager to effectively explain the rationale behind certain recommendations,” he says.
Talk in plain terms about time and money so the sponsor can make informed decisions based on the business case.
“If you need a decision made, you literally need to send a meeting invite that says, ‘Decision required: A, B or C — here are the implications of each,’” says Ken Hanley, author of Guerrilla Project Management and principal at KTH Program and Project Management Inc., a program and project management consultancy in Calgary, Alberta, Canada.

Sponsors and project managers may not see eye-to-eye on certain decisions. Be prepared to argue your case with the sponsor on the issues within your domain, such as the delivery of the project.

“If the sponsor’s decision will send the project or business over a cliff, it is the responsibility of the project manager to ensure that the sponsor and other decision-makers are aware of the risks they are taking and to try to provide them with sufficient analysis supporting the concerns raised,” Mr. Bondale adds.

Gaining support from others involved in the project doesn’t hurt, either.

“If there are peer-level stakeholders to the sponsor whom the sponsor respects and who support your view, you could engage their support in trying to sway the sponsor,” Mr. Bondale says.

When you do speak up to a project sponsor, you must do so tactfully. You don’t want to undermine them, but you must state your case. Have any potentially damaging conversations in private.

“Nobody likes being told they’re wrong in front of others,” Mr. West says. “If the project manager thinks the project sponsor is making an error, he or she should first try to understand what is causing this error.”

Although project managers have a responsibility to voice concerns, some sponsors might not want to consider another view. In the event of disagreements, be sure to document the issues with comprehensive written records.

“If the sponsor refuses to change their mind, it’s a good idea to document the decision and the alternatives — including yours — and get the sponsor to sign off on it,” Mr. Bondale says. “If the worst happens as a result of the decision, at least you have some evidence that alternatives were considered and the sponsor chose to continue down his preferred path.”

At the end of the day, you are the project lead. With a little tact and a lot of support, you can avoid doing any damage to your relationship with your sponsor — or your career.

Article shared from PMI:

http://www.pmi.org/Home/Professional-Development/Career-Central/Avoid-Conflict-with-Your-Project-Sponsor.aspx

How to effectively use a RACI matrix

2011-12-28T22:48:00.000-08:00

In some instances, there can be confusion between project staff in relation to their duties and responsibilities. Therefore, before the start of a project, it is essential that each person involved in the project be given a clear idea about his or her role. RACI matrix is a tool, which has been used to delegate the roles and the responsibilities in order to avoid such confusion throughout the lifetime of a project.

RACI is an acronym used for representing the terms Responsible, Accountable, Consulted and Informed. In certain instances, there may be additional terms being incorporated and the acronym may change to RASCI (‘S’ stands for ‘support’), RACIO (‘O’ stands for ‘Out of the Loop’) and RACI-VS (‘V’ stands for ‘verify’ and ‘S’ stands for ‘signatory’).

In any event, many managers use RACI matrix in its basic form in order to achieve smooth functioning of their projects. However, before going into the matrix, one should clarify the terminology involved in RACI.

Responsible – It refers to the person who works to achieve the task. They will get the work done or make decisions related to its achievement. For a given task, there should only be only one person ‘responsible’.

Accountable – The person accountable would be the person who makes sure the task would be completed according to the requirements. For a given task, there should only be one person ‘accountable’.

Consulted – There can be several people in this category for a given task and these people will give information for successful completion of the task. The communication with such individuals would be ‘two way’.

Informed – These are the people whom should be kept informed regarding the progress of the task and usually the communication with such individuals would be ‘one way’.

When it is time to assign the roles and begin the project, it is vital to recognize the tasks at hand in achieving the intended outcomes of the project. At the same time, the project staff should also be recognized. Following this, in order to create the RACI matrix, a table should be prepared with the recognized tasks tabulated according to their ordeDrr of completion one after the other in the first column of the table. Next columns will belong to the project staff and one column will represent one person. Now, for each task, indicate who will be Responsible, Accountable, Consulted and Informed by indicating the relevant letter for each task. However, it should be remembered that, for a single raw or for a single task there should only be one ‘responsible’ person and one ‘accountable’ person.

Finally, in order to create an effective and agreeable RACI matrix to all stakeholders, one should discuss it with the project staff during its creation before going ahead with its implementation.

About the author:
Dr. Pandula Siribaddana, graduated as an MBBS doctor from the Faculty of Medicine, University of Colombo and currently working as a Lecturer in Medical Education in the Postgraduate Institute of Medicine in the same university. My interests are mainly on IT in Medical Education.

Best Practices in Project Management - or Better Practices

2011-12-21T11:17:00.000-08:00

Best practices in project management are tried and tested processes collected from experiences and lessons learned. They've been repeated and improved to produce consistent outcomes. They are documented as examples, baselines and measures.

Project managers who favor best practices and processes believe it's unnecessary to "reinvent the wheel." They believe using best practices in projects has many advantages:

Project managers have access to tools, techniques, metrics and templates to use on their projects at any time.

Best practices provide consistency of expectation, activities and communication for the team.
They're generally driven by values and results, and can improve customer confidence.
Construction, infrastructure and power projects have best practices as industry norms to standardize quality, safety and other requirements.

Not everyone agrees with using best practices, however. Some argue against the blanket use of best practices because, frankly -- times change.

Best practices for projects from 10 to 20 years ago are outdated as technology and real time communications continue to evolve, for instance. More customers are aware of project management, resulting in changed expectations. And definitions of acceptability, constraints and assumptions may differ from the environment where these best practices originated.

I agree that we shouldn't reinvent the wheel. However, I do stress that the wheel should fit properly in order to fulfill its purpose.

Best practices are excellent if there is cooperation and consistency in an organization from top to bottom. Rigidly imposed processes that are unwanted and misunderstood cause problems and restrict new thinking.

Project managers should use best practices but they should build, fine-tune and improve them to fit an organization. Should best practices become better practices or best-fit practices so they become molded, enhanced and understood by the organization and the people who will benefit from them?

Article by Saira Karim for Voices on Project Management
http://blogs.pmi.org/blog/voices_on_project_management/2011/07/best-practices-in-project-mana.html

The Advantages of becoming a Macro Manager

2011-12-21T00:50:00.000-08:00

Richard Highsmith writes for PM Hut,

“When Alexander the Great visited Diogenes and asked whether he could do anything for the famed teacher, Diogenes replied: ‘Only stand out of my light.’ Perhaps some day we shall know how to heighten creativity. Until then, one of the best things we can do for creative men and women is to stand out of their light.” - John W. Gardner

Shine the light on creativity. Let the creative process work. Clearly define the goals and objectives. Give your employees support and freedom to reach those goals and then get out of their light. In this environment, team members will feel empowered to create new ideas and find creative solutions to old problems. Potential roadblocks will be anticipated and alternative routes quickly planned. Allowing a free-flow approach to work produces powerful enterprise - not busy work.

A wise leader allows originality and creativity to flourish by focusing on goals and objectives - not the niggling details. Set the parameters and allow people to flex their innovation muscles. Remember, creativity comes willingly from team members who feel appreciated and valued. Inspire your team by being an openly supportive Macro Manager.

Read full article at:
The-advantages-of-becoming-a-macro-manager

About the author:
Richard Highsmith, rick@qualityteambuilding.com, is President of Quality Team Building. He has twenty-five years experience training and coaching. He has built and sold two successful businesses. To learn more about becoming a team leader visit our website at http://www.qualityteambuilding.com or call Rick toll-free at 1-888-484-8326 X101.

What is Business Value

2011-12-21T00:40:00.000-08:00

The term “business value” is bandied around a lot these days when talking about the benefits of Agile software delivery. Agilists argue that more business value can be achieved through Agile than through traditional methods such as Waterfall.

But, what exactly are they talking about when they say “business value”?

I would define business value as something which is of potential short, medium or long term benefit to the business by means of increasing customer happiness and/or ROI. It doesn’t necessarily pertain to revenue or profit, at least in the short term. Sometimes you’re just trying to build a user base of people who love your product before you think about monetizing it.

I would say you are more likely to deliver functionality that provides business value by working in an Agile way. One reason for this is that the time between someone having a marketable idea and that idea becoming part of functioning software is far shorter in an Agile project than a Waterfall project. In fact, in a Waterfall project marketable ideas do not really have the opportunity to come to the surface at all because all requirements and design are defined up front, and even if you push a change through the change request process it still could be months before the idea gets built and put in front of users.

In an Agile project users will get their hands on the product very early so will be able to provide lots of input into the product’s evolution, and this input can turn into software updates very quickly. Thus the chances of ending up with a product that no one uses are far lower.

In short, by building things incrementally and iteratively it is quicker and easier to identify emerging business value.

About the author:
Neil Killick is a highly skilled I.T. professional with 17 years of varied experience in England and Australia. His background is in Java/Web development, but his more recent experience has encompassed being a ScrumMaster, Iteration Manager, Senior Agile BA and Product Owner, as well as a Team Leader, Coach and Mentor in Agile or transitioning environments.

Cloud, mobile, in-memory computing: Has SAP lost the plot?

2011-11-12T22:45:00.001-08:00

SAP has not lost the plot. They are re-positioning.

Warwick Ashford writes in ComputerWeekly.com:

SAP is betting on an innovation agenda to sustain its seven consecutive quarters of growth, but with all the attention on cloud, mobile and in-memory computing, is the business software maker in danger of moving too far from its core ERP business?

Innovation, was certainly a dominant theme at of SAP’s customer and partner event Sapphire in Madrid, but Jim Hagemann Snabe, co-chief executive at SAP was at pains to emphasise that SAP is innovating at the core as well as in mobile, cloud and in-memory computing.

Snabe announced that innovation around the core ERP business suite is ramping up from a six-monthly cycle to once every quarter, saying there is momentum at the core with lots more innovation to come.

“SAP believes a company needs to understand and grow from its core, and our core and 39 years’ experience is in the ERP business suite,” he said.

Snabe said the core remains important as a base for all the innovation at SAP. “We will not abandon the core; by revitalising the core and ensuring consistency, we are able to innovate faster at the edge with mobile and cloud,” he said.

Driving the point home, Snabe said while SAP was innovating at the core as a basis for all other innovation, some competitors were tearing everything down and offering something new.

Read full article:

News-Analysis-Cloud-mobile-in-memory-computing-Has-SAP-lost-the-plot

More about Warwick Ashford:

Warwick Ashford is chief reporter at Computer Weekly. He joined the CW team in June 2007 and is focused on IT security, business continuity, IT law and issues relating to regulation, compliance and governance. Before joining CW, he spent four years working in various roles including technology editor for ITWeb, an IT news publisher based in Johannesburg, South Africa. In addition to news and feature writing for ITWeb’s print publications, he was involved in liaising with sponsors of specialist news areas on the ITWeb site and developing new sponsorship opportunities. He came to IT journalism after three years as a course developer and technical writer for an IT training organisation and eight years working in radio news as a writer and presenter at the South African Broadcasting Corporation (SABC).

The SAAS development life-cycle

2011-10-31T12:07:00.000-07:00

Cloud service development requires a different approach than the traditional software development lifecycle as the cloud provider becomes a critical success factor of the overall project. In a traditional software development setting, more emphasis is put on the functional aspects because it is deployed on an on-premise infrastructure with implicit security, compliance, control, operational transparency and perceived service level requirements. Another important factor is the cost of operations. It often takes back seat, especially in cost centers, due to the sunk cost and horizontal charge models. The main objective of this paper is to focus on the lifecycle aspects of SaaS service development and outline the motivation, inputs and deliverables of each activity for all the phases of the lifecycle. Cloud services can be built for internal consumption as well as for selling to external customers. The focus of this article is the cloud services built for external consumption as these require rigorous architecture practices to incorporate the service tenets necessary for a successful services business model. Even though the SaaS (Software as a Service) Development Lifecycle outlined here is scoped at external facing services, the process can easily be adopted to internal private cloud based applications that target internal users. It is clear that even enterprise IT departments have to start looking at themselves as Service Providers and act accordingly.

The SaaS Development Lifecycle (SaaSDLC) is an adaptation of the traditional iterative software development process with additional important phases added. These additional phases – Evaluation, Subscribing and Operations are less prominent and implicit for on-premise deployments. However, the activities during these phases become critical success factors for a SaaS development and deployment due to an externalized multi-tenant hosting environment. While the initial SaaS projects require more emphasis on the cloud provider evaluation, subscription acquisition and operationalizing the services, the subsequent SaaS efforts can leverage the know-how acquired previously thereby allowing the project teams to short circuit Evaluation and Subscribing phases. The IT Professional needs to be extra diligent in cloud platform provider evaluation, designing the deployment environment and setting up operational processes that integrate cloud providers processes and frameworks into the existing management and monitoring environment.

Read the full article at:
http://www.infoq.com/articles/SaaS-Lifecycle

About the authors:

Hanu Kommalapati is a Senior Technical Director at Microsoft Corporation where he is the technical lead for Windows Azure and Cloud Computing for the U.S. subsidiary of Microsoft's Platform Evangelism organization. In this capacity he works spreading the word about Cloud Computing to Microsoft customers, partners and community.
In the past he has held positions as Principal Platform Strategy Advisor and as an Architect for Microsoft. Previously he also held positions as a Principal Consultant at PricewaterhouseCoopers.

William H. Zack Is a Microsoft Principal Architect Evangelist who specializes in architecting, implementing and supporting both applications and computing infrastructures based on Microsoft Internet, Intranet, Client/Server and Cloud technologies. Over the past three year years Bill has been evangelizing Windows Azure and working with customers and partners to help them design, build and move applications to the Windows Azure Cloud Platform.

End the holy war over agile development

2011-10-31T11:38:00.000-07:00

Bob Lewis writes in Java World:

Why agile is essential for next-generation IT

Depending on whether you're a proponent or a detractor, agile is either a family of methodologies or a religion composed of one true denomination and a handful of variously misguided sects whose only virtue is being less misguided than the waterfall contingent. The same may be said for waterfall, only backward.
In fact, for all the religious fervor, the question of which methodology is superior can only be answered by the phrase business managers like least from consultants: "It depends."

Without a doubt, next-generation IT organizations will have to master agile. Why they'll have to master it has nothing to do with "I want to run an agile project" and everything to do with "it depends." Specifically, "it depends" boils down to two factors: how fast a company needs a solution, and how long that solution will have to last. In an increasing number of business situations, deadlines and lifespans are getting shorter all the time -- criteria for which agile is well-suited.

The upside of agile is that businesses that implement it are great at adapting to change quickly. That's because the software supporting the business is built in small chunks that are deployed quickly and bring business benefits early. When business circumstances change before the next chunk is supposed to be ready, it doesn't matter, because agile designs are just in time, not all at once.

Agile is great at one more thing: graphical interfaces that fit how users want the software to operate. That's because agile calls for high levels of informal interaction between developers and users, without any need for intermediaries.

Does that make a business more agile? It sure does, because the better the software fits how users think about their work, the less time they'll need to learn it, and the less often they'll misuse it when taking care of oddball situations.

Moving IT beyond agility

Where does this leave someone trying to take IT into the next generation?

Every business of any size and age has some areas subject to rapid and unpredictable change, and others that are, for the most part, stable. IT has to be able to support both, which means using agile and waterfall techniques based on what the situation demands, not personal preference.

In other words, next-generation IT has to be something even more difficult than agile: It has to be versatile.

Read the full article by Bob Lewis at:
http://www.javaworld.com/javaworld/jw-10-2011/111026-advice-line.html

About the author:
Bob Lewis is president of IT Catalysts, Inc., an independent consultancy specializing in IT organizational effectiveness and business integration. He's the author of Leading IT: (Still) the Toughest Job in the World, nine other books, and more than 800 articles on managing information technology organizations.

The changing Role of Technology in Project Communication

2011-10-10T21:01:00.000-07:00

V. Srinvivasa Rao writes on this very interesting topic for Voices on Project Management.

The first global delivery model (GDM 1.0) was created a few decades ago to reflect the outsourcing and offshoring of IT services, mostly in India. A global delivery model is typically a method of executing a technology project using a team that is distributed globally.

Now, there are many choices in terms of outsourcing, and technology plays more of a role in project communication. As such, GDM 2.0 is on the horizon. And project managers must reorient themselves to the changed environment of cloud, social and mobile computing.

I would describe GDM 2.0 as "intelligently distributing the project's work, team, leadership and governance across multiple locations and leveraging technology to provide high-speed, high-quality and low-cost solutions to global customers."

A few of the tenets that contribute to providing customer value using a GDM 2.0 are:

Reduced cost: Executing projects at low-cost locations spanning multiple countries, cultures and languages

Abundant talent: Accessing talent across different locations

Follow the sun: Leveraging time-zone differences to maintain continuity in managing projects

Quality of service: Using best practices, lessons learned and standards to provide faster, better, cheaper and steadier services

Knowledge and collaboration: Implementing robust knowledge-management systems to help build a seamless flow of information across multiple teams, projects and locations

Continuous learning: Using ongoing training to prepare project professionals for the market, customers and projects

Here are a few of my thoughts on the future of GDM 2.0:

1. Almost all IT service providers are now building their own private clouds, making the provisioning of IT resources faster and cheaper. In the past, project managers had to wait for weeks or months to get certain IT resources.

2. IT service providers that develop applications using platform as a service (PaaS) and that implement package applications using software as a service (SaaS) now involve cloud providers. Project managers must be aware of the various risks, contractual obligations, security issues and potential legal issues of working in this multi-party environment.

3. IT service providers are building process platforms that leverage cloud infrastructure. That means project managers must learn to work with competitors, as customers might select process platforms from multiple IT service providers.

4. Mobility in project management will be a norm in the GDM 2.0. IT service providers have to mobilize their project management, software engineering and other critical governance processes to improve project performance. These service providers will need to make investments to rebuild their project management tools and applications to work on mobiles or to procure mobile project management applications.

Establishing a Culture of Acknowledgement

2011-10-10T20:14:00.000-07:00

An insightful article by Judy Umlas that highlights the basics of establishing a culture of acknowledgement.

1. If you're a project leader for a new team, all the better. At your project kickoff meeting, announce that you have heard about the value of acknowledging team members for their accomplishments, and for who they are and what they bring to the team.

Be clear that people should only acknowledge team members that they truly feel deserve it. Otherwise, the acknowledgment will fall flat and be considered insincere. If the project is already underway, set up some specific time to discuss this at one of your regular project meetings.

2. Make the statement that everyone has a unique talent or gift that they bring to the team. Stress that they are all tasked with finding these gifts and talents.

3. In my book, The Power of Acknowledgment, I discuss 7 principles of acknowledgment, which can be summarized as follows:

The world is full of people who deserve to be acknowledged.
Acknowledgment builds intimacy and creates powerful interactions.
Acknowledgment neutralizes, defuses, deactivates and reduces the effect of jealousy and envy.
Recognizing good work leads to high energy, great feelings, high-quality performance and terrific results. Not acknowledging causes the opposite.
Truthful, heartfelt and deserved acknowledgment always makes a difference in a person's life and work.
Acknowledgment can likely improve the emotional and physical health of both the giver and the receiver.
Practice different ways of getting through to the people you want to acknowledge.

Ask people how these principles "show up" for them. Do they recognize that being acknowledged is an innate human need? Without it, people cannot survive, let alone thrive.

4. Share with them Stephen R. Covey's quote from 7 Habits of Highly Effective People: "Next to physical survival, the greatest need of a human being is ... to be affirmed, to be validated, to be appreciated."

Keep the conversation about acknowledgment going throughout the life of the project. Then, do a wildly successful job as a team. The culture of acknowledgment and appreciation will allow that to happen.

How do you create a culture of acknowledgment within your project teams?

Article by Judy Umlas for Voices on Project Management.

Serve your customers not your processes

2011-10-07T00:25:00.000-07:00

I tend op agree with Snyder in his article for PM Hut that we need to put ourselves in the shoes of the customer when addressing their concerns. I have heard many times how employees explain company processes to customers when addressing their problems. Is it because the processes makes employees feel safe that they tend to hide in it's comfort zone. Processes are guidelines to address issues and should not be used as the argument when addressing customer complaints.

Ben Snyder writes in PM Hut,

Most organizations are service oriented. Either they are serving external customers or internal customers. Serving customers involves lots of interactions in a variety of circumstances and situations. Individuals who are customer facing and handle customer issues need to be engaging and empathetic to do their job well. This is the first rule of customer service.

It is normal for organizations to develop processes for serving customers so they can be more efficient in their efforts and consistent in their quality. These processes are usually developed with the customer in mind but they always aid the organization more than the customer. In addition, like all process they only address the majority of the potential situations, not all of them.

A common problem for service oriented organizations is that their people engage and serve their processes and not their customers. The processes become an insulator between the customer and the organization. People in the organization view a customer’s issue as just one of many that they have to deal with. But on the other hand, the customer views their issue as one of a kind and very unique to them. This sets the stage for a frustrated customer. They do not feel as though they are being engaged properly and they experience little empathy from the organization. If the customer’s issue is truly unique there ins’t enough engagement on the organizations part to recognize it; the organization assumes it is just one of the same issues they deal with every day. It is not hard to see how this leads to a bad customer experience.

To avoid this, organizations must instill in their people a heightened desire to see all issues from the customer’s perspective. They must use process to ensure consistent quality but be prepared to deviate from them to engage a customer’s unique issue even if it is inefficient to do so. Lastly, organizations need to make sure their people realize that every opportunity they get to serve the customer is an opportunity to increase the customer’s desire to work with their organization. This is the surest way to achieve job security. Serve your customers and not your processes.

About the author:
Ben Snyder is the CEO of Systemation, (www.systemation.com), a project management, business analysis, and agile development training and consulting company that has been training professionals since 1959. Systemation is a results-driven training and consulting company that maximizes the project-related performance of individuals and organizations. Known for instilling highly practical, immediately usable processes and techniques, Systemation has proven to be an innovative agent of business transformation for many government entities and Fortune 2000 companies, including Verizon Wireless, Barclays Bank, Mattel, The Travelers Companies, Bridgestone, Amgen, Wellpoint and Whirlpool.

A day made of Glass

2011-10-05T14:57:00.000-07:00

This is certainly going to see the light in the not too distant future.

Overcoming hurdles for Project Managers when Transitioning to Agile

2011-10-05T13:17:00.000-07:00

When organizations decide to transition from traditional approaches to agile ones, this change impacts all project roles but the most drastic shift could be that experienced by project managers.

This is especially true for organizations that are at a high level of project management maturity. In these, project sponsors or owners are likely already used to working closely with the project team and are comfortable with the need to be actively engaged in refining and prioritizing requirements. Project team members are also used to pro-actively informing their project managers of issues and provide their task progress updates using quantitative effort remaining estimates instead of the less trustworthy percentage complete.
For project managers, however, the shift in the nature of their roles is likely to be more significant.

On a traditional project, during planning and execution phases, the project manager plays a very directive role and may even act with a reasonable amount of authority. On the agile project, this approach won’t work as it could stifle or throttle the communication flow between the team and the customer and can reduce the empowerment of the team to get the work done.

A project manager that is used to spending hours on administrative activities such as managing change requests, updating massive project schedules and producing voluminous status reports will suddenly find themselves with less need to focus on the artifacts of the PM process and greater ability to facilitate communication between the customer and the team as well as being actively engaged in removing any and all roadblocks towards achieving optimal velocity.

This shift from administrative and directive activities during the core project phases should not faze PMs with well honed soft skills but for the less seasoned practitioners it is a good idea to be paired up with an agile-savvy mentor who has sufficient availability (and patience!) to be able to participate as an observer to scrum sessions, iteration planning meetings and iteration retrospectives. The beauty of agile is that the PM is able to receive actionable feedback at multiple times over the lifetime of the project without the need to wait till the project is over to know how they did and what could have been refined.

Project management is all about realizing change, but sometimes the hardest change to effect is in ourselves!

Article by Kiron Bondale(Twitter: @kbondale) for PM Hut.

Kiron D. Bondale (PMP) is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

Seven Sins of Cloud Computing Service Delivery

2011-10-02T18:12:00.000-07:00

Cloud computing have been in our midsts for a long time. Knowingly or unknowingly, as users, we have been exposed and used cloud computing for a long time for eg. Google and many other online services and storage facilities. Cloud computing is the future!

Force.com says in article:

The technology industry has changed dramatically over the last 10 years. In economic times like these, leading companies are looking to cloud-computing platforms to deliver business functions ranging from packaged business applications to custom application development at a fraction of the time and cost of traditional on-premises platforms. With this growth in enterprise use of cloud-computing comes a corresponding increase in responsibility on the part of vendors to provide cloud-computing platforms that offer outstanding service delivery.

The building blocks of the best practices every successful cloud-computing platform should follow:

1. World-class security – Provision world-class security at every level.

2. Trust and transparency – Provide transparent, real-time, accurate service performance andavailability information.

3. True multitenancy – Deliver maximum scalability and performance to customers with a truemultitenant architecture.

4. Proven scale – Support millions of users with proven scalability.

5. High performance – Deliver consistent, high-speed performance globally.

6. Complete disaster recovery – Protect customer data by running the service on multiple, geographically dispersed data centers with extensive backup, data archive, and failover capabilities.

7. High availability – Equip world-class facilities with proven high-availability infrastructure and application software. Force.com is the only cloud-computing platform that adheres to all seven of theses standards.

Can PMO's and Centres of Excellence Coexist?

2011-09-20T13:15:00.000-07:00

Project Management Centers of Excellence (PMCOE) are becoming increasingly popular as a solution for organizations to streamline their processes while increasing efficiency, profit and competitiveness.

Generally, a Center Of Excellence (COE) is a business unit that has organization-wide authority. It coordinates continuous improvement initiatives, ensures that value is achieved in all areas, and fulfils the role of organizational thought-leader or consultant.

COEs are also created to capture an organization's best practices, standards and industry benchmarks. The COE facilitates the approval, transfer and integration of these best practices across the organization. For example, in a global manufacturing company, the COE may identify a best practice used in its European plant, tweak it, and implement the practice in its Saudi plant, too.

There seems to be confusion between the roles of a Project Management Office (PMO) and a PMCOE. Some argue that the PMO sufficiently leads the organization to project management excellence. So, why would an organization with a well-structured PMO need a PMCOE?

In his book, Advanced Project Management: Best Practices on Implementation, Second Edition, project management expert Dr. Harold Kerzner states:

"The definition of project management excellence must extend well beyond experience and success ... Success is measured by having achieved performance that is in the best interest of the whole company, as well as having completed a specific project."

PMOs and COEs are only successful when they achieve the objectives for which they are created. Leaders in the profession note that the number of projects or years an organization has been delivering projects can't define project management excellence. Neither can the methodology it follows.

Larger, complex organizations may need a PMO and a PMCOE -- but their roles should be clearly defined.

A PMO is an important central hub with a mandate to coordinate and deliver all project activities as determined by the organization's needs.

PMCOE executives would operate as part of the business decision-making process. These individuals would report on the organization's project portfolio as a whole and provide the organization with project consultancy.

The PMCOE also supports the PMO through research, innovation and leadership initiatives and bridges the gap between PMO teams and business units within the organization.

Article by Saira Karim for Voices on Project Management.

Windows 8 – Finally Providing Competition for Linux?

2011-09-13T15:50:00.000-07:00

The “one platform” approach

Windows 8 retains the “old style” Windows desktop as, essentially, another app in the Metro interface. The result is a single OS that is both tailored to tablets, but also to mouse-bound desktop users.
On a Linux related note, Ubuntu 11.04 saw Canonical fold the various netbook spins of Ubuntu into the main release. Similarly, although Canonical insist that Ubuntu is not heading to the tablet sector any time soon there’s no denying that various developments to the Ubuntu interface – particularly with regard to Unity and uTouch – mean Ubuntu already functions well on a tablet, although is by no means ideal.
Windows 8 is being sensible in this ‘unification’ approach. It’s less confusing for consumers, and easier for developers. That said, I still somewhat expect Microsoft to stuff it up by announcing an ensemble of “Tablet Edition Premium” and “Desktop Metro Home Professional” varieties.

Article by Joey Sneddon for OMG Ubuntu

Read full article at: http://www.omgubuntu.co.uk/2011/09/windows-8-interesting-competition/

Mitigating Risk with Project Advocacy Consultants

2011-09-13T15:01:00.000-07:00

Besides scope, time and budget, the core of project management success is stakeholder acceptance of project deliverables. As such, the risk of stakeholders rejecting deliverables should be identified and mitigated in a project's early stages.

For example, stakeholders in infrastructural development projects, like members of a surrounding community, make certain choices about project execution, such as location, quality and schedule. But, this doesn't always happen. If residents, say, are denied vehicular access to their homes because of an ongoing road re-construction, it's clear there was no stakeholder representative during the execution planning of the project.

African governments often rely on public private partnerships (PPPs) for utility and infrastructure projects. But most proponents of PPPs settle for a design-bid-build business arrangement, in which a single vendor may win concessionary bids to develop, operate and transfer utility infrastructure schemes. In this instance, a concessionary bid is a solicitation process for PPP projects.

This kind of business arrangement increases the risk of eroding the values and interest of that community. Sponsors and vendors could decide to satisfy themselves to the detriment of the residents or other project beneficiaries.

One way to mitigate the risk of communities rejecting infrastructure projects could be to use project advocacy consultancies, which are composed of community and government representatives. The committees ensure that infrastructure projects address the needs of the communities and are accepted by them.

In Africa, it would be a major stride in project management if stakeholders approved of the deliverables of PPP infrastructure projects. Of course, projects would be more widely accepted if communities were involved during the planning and execution of deliverables.

In my opinion, highly leveraged infrastructure projects that are initiated under concessional business arrangements and executed without the involvement of the would-be users should be discouraged. In turn, profits made by promoters and vendors from infrastructure projects could be better justified vis-à-vis community acceptance of the deliverables.

If communities approve of infrastructure projects, post-project operations and facilities management, it would benefit everyone. Promoters would smile at the projected cash flows, vendors would satisfy both contractual and project obligations, and ultimately, the project would be successfully completed.

Article by Lambert Ofoegbu, PMI-RMP, PMP, OPM3 for Voices on Project Management

10 Years of Agile - the Prophecy of Failure and the Failure of Prophecy

2011-09-13T13:56:00.000-07:00

If complexity is going to be happen anyway, we have to allow those patterns to emerge from the interaction of people on projects, and from the interaction of those projects themselves. We're guilty, as a community, of signing up to "individuals and interactions over processes and tools", then mandating processes to control the interactions, while supporting the processes - and not the interactions - with tools. In future, the practices we teach will be those which enable interactions, rather than controlling them. We've seen this already with the rise of metaprocesses like Kanban. Models for understanding complexity, and particularly the complexity of people, are also being taught in Agile conferences worldwide - Systems Thinking, Complexity Thinking, psychology and sociology.

These are also the kind of practices we need to change behaviour at higher levels in the organisation; to make the impact of anti-patterns apparent. We haven't seen as much change as we prophesied at the beginning. Maybe over the next ten years, we'll see a different manifesto emerge - one which starts, "We are uncovering better ways of enabling change by doing it and helping others do it."

About the author:
Liz Keogh is an experienced Lean and Agile coach, trainer, blogger and well-known international speaker. Coming from a strong technical background, her work covers a wide variety of topics, from software development and architecture to psychology and systems thinking. She is best known for her involvement in the BDD community, and was awarded the Gordon Pask award in 2010 for deepening existing ideas in the space and "coming up with some pretty crazy ones of her own".

Read full article at:
http://www.infoq.com/articles/agile-prophecy-failure

Different Perceptions of Risk on Projects

2011-09-12T17:35:00.000-07:00

1. Risks as facts: Risks are treated as objective, technical, neutral events that can be managed based on the knowledge produced by objective analysis using probabilities and expected values. The outcome is rational decision making.

2. Risks as subjective constructions with multiple dimensions: Risk managers choose the context and perspective they adopt. This allows multiple rationalities to coexist, depending on the values and perspectives of the observers. (This explains why some people find jumping out of an aircraft fun.)

From a project perspective, risks are uncertainties that matter. All estimates about future project outcomes incorporate a degree of uncertainty. This includes the three key dimensions of project management: timing, cost and quality of future project deliverables.

The project manager cannot be certain that the estimates that make up the project schedule or cost plan will prove to be correct, or that the project team will create deliverables to the appropriate quality standards. The rational management approach is to assess the risk factors and develop appropriate time and cost contingencies, backed by appropriate reviews and tests to ensure optimum quality. This approach is highly objective and rational.

However, you cannot rely on your stakeholders having the same view as you. If a stakeholder sees your project in a different context, their perspective on risk will be different.

For example, if you created a contingency plan using a Monte Carlo analysis, an executive may interpret the plan as a sign you don't understand the project because he or she expects a single definitive result. From this stakeholder's perspective, the precise calculation of a critical path method schedule offers certainty and minimum risk.

The authors of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) have a different perspective, which understands the benefits of 'three-point estimating.' You cannot assume your stakeholder will have the same view.

The challenge is to accept that a range of stakeholder perspectives will occur. Stakeholders may derive completely different opinions from the same data.

You should anticipate this possibility and adjust the way you package your project information to communicate more effectively and ensure both you and your key stakeholders have a common understanding of the risks and issues confronting you project.

Article by Lynda Bourne, DPM, PMP

Cloud computing meets Project Management

2011-09-11T18:33:00.000-07:00

Excellent article by Raj Asava and Hussien Mzee.

Jun 2010 - PMWT Featured Paper - Asava Mzee - Cloud Computing meets PM - FINAL.DOC - Powered by Google Docs

The Three Ships in Fleet of Success

2011-08-04T23:22:00.000-07:00

Kerry Wills writes in PM Hut:

I believe there are three ‘ships’ that are essential to be in your fleet of success. I am not talking about the Nina, Pinta and Santa Maria. I mean the following three essential skills:

OwnerSHIP Ownership means truly feeling accountable for the work and projects you are on. This means not just focusing on a particular task and hoping others will do theirs. This is genuinely owning all work even if you are not directly responsible for it.
StewardSHIP
Stewardship means caring about your work, the project and the company. Being a good steward means doing the right things for the company, growing the people around you and looking to improve things that are broken.
LeaderSHIP
Leadership is the ability to motivate and influence others to meet common goals. It also means being a champion for your team and supporting them.

I don’t see how a project manager can be successful without all three. If they don’t feel ownership of the project or stewardship to the organization, then there will be oversights and missed commitments. Without leadership, the team won’t be successful or feel motivated to do the work and key stakeholders won’t be influenced on key decisions.

Influencing Senior Project Managers

2011-08-04T22:30:00.000-07:00

How do you change a stubborn senior manager's mind? For example, he or she might claim your project only needs six weeks to complete, even though you have a carefully researched and resource-loaded schedule that proves 10 weeks is needed.

Arguing won't work. In fact, given the power structure, arguing will simply put you in a worse position. Doing nothing simply delays the problem and you will eventually be held accountable for your perceived failure to meet the stakeholder's unrealistic expectations.

To change a senior manager's mind, you need to change the manager's expectations. Though you may battle a heavy overlay of skepticism, use of effective communication and a planned strategy should do the trick.

Effective communication requires that at least two of the following three elements be present:

•   You're known as a technical expert.
•   You're credible: People know you provide reliable and accurate information.
•   The information you're communicating is relevant to the receiver.

Influencing a skeptical senior manager requires you to boost all three facets. You cannot do this alone. Some options to consider include:

Co-present your case with a trusted source. You increase your chances of success by sharing the stage with someone the executive trusts. Build the value of your ideas on the credibility the co-presenter has established with the executive.

Demonstrate endorsements to build power. Ask others in positions of power to let the executive know they support your idea.

Stroke egos and use the executive's credibility. Authentically move ownership of "the" idea -- not "your" idea -- into his space. You can do this by using phrases such as "You've probably seen this data already," or "I'm sure your analysis has shown similar results."

These approaches need organizing and take time but are essential if you are going to effectively advise upward.

Article by Lynda Bourne for Voices on Project Management

Agile Methodologies not the answer to all Projects

2011-08-01T21:29:00.000-07:00

Kiron D. Bondale in an article for PM Hut explains:

The allure of agile is seductive – an organization tries it with one or two projects, experiences greater success than they’ve achieved historically with waterfall approaches and decides to apply this new methodology to all projects. The risk is that when they hit a project that was not well suited to agile methods, the temptation to throw the baby out with the bath water is compelling and they revert to their previous approaches.

So what are some criteria that might rule out the use of agile methodologies?

I’ve written before about the importance of trust on projects and this affects agile projects to a greater extend than waterfall ones – environments with low levels of trust might be better suited to traditional approaches where rigorous (though onerous) decision & deliverable sign offs and change approvals could reduce the likelihood and impacts of finger-pointing.
Projects where real-world constraints prevent the ability to re-factor components or to refine requirements through an iterative approach. When one is laying a building’s foundation, you usually only get one chance to do it right and the costs of rework are significant. This is not to say that construction projects can’t benefit from agile approaches (especially during the creative or design phases), but their utility will be restricted to those work packages that can support progressive evolution.
Projects that impose significant “hops” between the customer and the delivery team. This has nothing to do with geographic distance – there have been many successful virtual agile projects. The issue arises when requirements are distilled and translated multiple times from the customer to the team members. The likelihood of miscommunication and rework increases to the point where a traditional approach might yield better results with less effort.
Minimal or no change is expected to the requirements. If a project’s needs are very well understood by both customer & team, a traditional waterfall approach may be a better fit. A good example of this could be an application upgrade driven by the need to maintain vendor support (as opposed to re-engineering business processes).
Time-sensitive projects with project teams or customers that have not used agile methods before. As with any methodology change, the first time a practitioner experiences it, there is a resulting loss in productivity as they come up to speed on the new methods. If there is a deadline looming, sometimes tried and true approaches (though less efficient) should be employed.
Industries where strong external regulatory requirements drive the need for heavy artifacts or strict adherence with well documented processes. While agile methods can be used during research or analysis phases on such projects, product development and manufacturing phases in such domains are forced to use waterfall approaches to satisfy these compliance needs.

Agile is a way of thinking and once can find a way to apply agile principles in almost all projects but agile methodologies are not a universal solution.

The Benefits of a Change Control Board

2011-07-22T14:58:00.000-07:00

A CCB can be a small group of project team members who are willing to review and approve or reject change requests. Even if your projects are small, it's better to have some semblance of a CCB than to have none at all.

A CCB can help you manage the myriad changes that will come your way as a project kicks off. Your sponsors, stakeholders and project delivery team may all have agreed on scope, cost and schedule -- but it's inevitable that something will change before the project closes.

Those changes come in many shapes and will impact your project positively and/or negatively. A CCB helps you figure out which changes are acceptable to undertake, which aren't and which can be shelved.

Instead of shunning change or accepting every idea without examination, use the CCB to determine the best course of action for the project.

There will be times when members of your project delivery team have great ideas for the project, for example. After all, they're right in the mix during the execution phase and can clearly see where things could be improved. If you always shoot those ideas down, you will create strife between yourself and your team.

You may find no one comes to you with great ideas anymore. Part of a CCB's job is to listen to all ideas, carefully consider the merits, and explain to the project team (or stakeholder or sponsor) why an idea was approved, rejected or held until more favorable conditions arise to implement it.

A CCB can be more than just a repository for tracking changes and a governance tool. A CCB can show team members and stakeholders that their ideas are worthwhile and innovative, and can help foster those ideas that most positively impact a project.

Article by Taralyn R. Frasqueri-Molina for Voices on Project Management.

Facebook boosts Google+ expansion

2011-07-05T21:35:00.000-07:00

Facebook is fast becoming fertile ground for Google+ expansion. Facebook's success as a ginormous social network and open policies for information flow is perhaps an unexpected surprise that is aiding the growth of Google+ membership tremendously.

I sent a tweet a day ago for anyone to share a Google+ invite with me. I did not receive a response. With some limited research I found StuckInCustoms, that outlined a few easy steps to obtain a Google+ invite. Within a few seconds of providing my gmail address in one of the invite threads on the Stuck In Customs facebook fanpage, my Google+ account was set up. What was amazing was that requests for Google+ invites literally became viral. Well the idea is to pay it forward and help others to gain access to the Google+ network.

The apparent shutdown of the Google+ server has not been an obstacle at all as more people are added to Google+ every second. It has all to do with the opportunities that Facebook offer.

I doubt that Google+ will become a threat to Facebook in the near future. A big part of the hype right now is the human syndrome of "want to be part off". In my opinion, Facebook will remain the preferred social platform and Google+ will play catch-up, or that remains to be seen.

Although interest Google+ has necessitated the apparent shutdown of their server, it has certainly garnered enough reason and opportunity for them to aggressively employ programmers to make Google+ more competitive.

Must Project Managers be Technically Savvy?

2011-06-28T22:02:00.000-07:00

Luc Richard writes in an article for ProjectSmart:

"Must project managers be technically savvy? This topic always seems to cause quite a stir. While some believe that all you need to manage a project is a PMP certification, others are convinced that you can't successfully manage a software development project unless you truly understand the intricacies of the product.

I agree! To be an effective project manager, you must know the ins and outs of your solution. You must be capable of designing and developing the solution yourself."

I do not agree that project manager's need to have the technical know-how on specialized products. What becomes of working in a project team and the sourcing of expert advice when needed. It may just be this know-all attitude that may result in a failed project.

To be a successful project manager requires an understanding of the methodologies of project management, for eg. scheduling, estimating, resource allocation, risk, communication, quality etc. , and be a strong communicator. It also requires the ability to motivate project team members towards excellent, and using the best ideas for project success.

I would agree with Richard's that knowledge of product or required end result is important, but not to the expert level he suggests.

Read Richard's full article at:
Must-project-managers-be-technically-savvy.html

Whistler, BC, Canada

2011-06-24T20:03:00.000-07:00

Whistler is one of my favorite places during winter. Apart from all the activities, the scenery is amazing.

Don't get stuck in the Cloud

2011-06-22T23:45:00.000-07:00

Cloud computing offers a value proposition based on convenient services that you pay for as you go. Customized solutions can be offered in a flexible and secure environment. Companies can offload their non-core technologies and focus on their core businesses, providing a better product for their customers.

But cloud computing is based on the premise that users will always have access to the cloud service. Managers need to ask themselves what would happen if the service were unavailable. What if the cable from their internet provider were cut or — as has happened with alarming frequency lately — the service were disrupted by hackers or technical glitches?

The key issue is access to the data. Servers and technology can be found at secondary sites, but if the data is locked in the cloud, the business's ability to function may be severely compromised. On my plane, which had no Wi-Fi, I was without access to the source data. The format of the data on the Kindle probably wasn't compatible with other devices, even if I could have extracted it and the software licenses had allowed it. I did have the data (the book) on my iPhone, but reading a book on an iPhone screen didn't appeal to me and I had no way to connect the phone to the iPad.

Cloud computing is the future. It is winning over entire industries — including traditional late adopters such as health care. The keys to success are careful planning of a migration strategy and understanding that the cloud approach is adolescent in places (remember the early days of the internet?) and that problems will occur. If you're still window shopping, it's time to start catching up on your reading about the cloud. But if you do so on a plane, remember to take a real book along, too.

Read full article by Robert Plant for HBR:
Dont_get_stuck_in_the_cloud.html

Is it 'us vs. them' or 'all together now'?

2011-06-20T20:09:00.000-07:00

Great article by Paul Glen for Computerworld.

Over the years, I've noticed the power that a few simple words have to determine how project teams relate to their sponsors: "client," "customer," "we," "us," "them" and "partner." It's odd how little attention is paid to these words, given the critical role that the relationships they describe play in the success or failure of projects.

As a consultant helping to launch new projects or turn around troubled ones, I listen carefully for these words, because they tell me all I need to know about the relationship between project team and sponsor. When I hear "client," "customer," "us" or "them," I know that the team is working in a transaction mode. "Partner" and "we" indicate that they are in a relationship.

Relationship mode has only team members, not opponents. The team members represent different functional areas, but they are ultimately part of a collective. They jointly define common goals and expected standards of behavior. Together, the team members work to balance the common goals they commit to and the goals of each functional area that the members represent. The balancing act is more collaborative. Information is handled more transparently, and problem-solving is a joint effort. Together, the team places a higher priority on maintaining the long-term relationship, since they expect to continue working together after the completion of the project.

While each mode has advantages and disadvantages, relationship mode tends to yield better results and lead to a better work environment for everyone involved. Teams in relationship mode find motivation in their commitment to one another. When the dynamic is transactional, the participants find motivation outside the team. Teams committed to their buddies are more steadfast than ones devoted to a concept or a distant client.

So before you automatically start calling your sponsor your "client," give the relationship some serious thought. One little word at the beginning of the project can make a huge difference.

Read full article at:
Is_It_Us_vs._Them_or_All_Together_Now

Project teams and 'the avoidance collusion'

2011-06-20T18:46:00.000-07:00

Great article by Paul Glen which addresses the phenomenon of avoidance as a commonality in project teams. Avoidance may be more prevalent in functional structured organizations where project team members are added to a project, not having the project as main concern because it is an additional task to their employment.

Sometimes it feels as if our basic assumption about project leadership teams is that they can't work well together -- as if collaboration is out of the question and we're ready to settle for a cold peace based on limited communication and mutual suspicion.

The prototypical project leadership team consists of a project manager, a technical lead and a business sponsor. Their relationships form the core of the project culture, which spreads out to the rest of the team. If the core group works well together, displays patience and respect for one another, adopts common goals, and trusts one another, the rest of the team tends to interact accordingly. If they treat each other with legalistic caution and reserve, that too spreads throughout the team. The tone is set in that core.

The three people who fill these roles tend to be very different from one another. They represent the interests of dissimilar parts of the organization and have different educations and professional experiences, which give rise to distinctive assumptions about how businesses should work and even different ways of talking. And they tend to have rather divergent behavioral styles -- styles that reflect the very different departmental cultures they represent.

But they do have at least one thing in common -- though it seems to undermine their collective collaboration. That one thing is what I call "the avoidance collusion," which stems from the fact that none of them is terribly concerned about his relationships with the other two.

Read this excellent full article by Paul Glen for Computerworld:
Projects_and_Avoidance

Nine Common Project Estimating Pitfalls

2011-06-16T19:22:00.000-07:00

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.

Article by Brad Egeland, a seasoned project management professional:
Nine-common-project-estimating-pitfalls.html

Project Management Best Practices

2011-06-16T19:11:00.000-07:00

Practical application of these best practices drives a consistent project management approach, and tangible business results:

Quicker ramp-up of project managers
Easier integration of projects in a multi-project environment
More productive project managers (not inventing processes and tools on the fly)
Equips project managers with tools to “fill the gaps” in the client environment
Better overall team performance – delivering on customer expectations (including measurement of performance)

These are the tangible business results that separate good project managers apart from “the pack”.

Read the full article by Steve Hart for PM Foundations:
http://pm-foundations.com/2011/06/11/top-6-project-management-best-practices/

Successful Facilitation

2011-06-08T20:50:00.000-07:00

When major disagreements arise within an organization, a facilitator is sometimes needed to help work things out. A facilitator is one who works with a group of people to help make it easier to resolve a situation. Facilitation is very beneficial because issues are discussed thoroughly. Problems are often solved at the root level–not just on the surface. Team members are able to discuss and create plans as experts.

During each facilitation meeting, there is always a clear direction or objective. There is a lot less “rabbit chasing” and a more focused approach to the topic. The facilitator works to involve everyone into the conversation. The facilitator also ensures that all decisions are carried out and supported after the meeting has ended.

The facilitator’s role during each session is important to keep everything on track. He or she must have strong communication skills and the ability to expose the real issue at hand while remaining neutral. Negotiation skills are a must when coming to a consensus with which everyone can agree. Patience is a virtue when it comes to facilitation. He or she must avoid going for the quick solution to the surface problem rather than dealing with the root problem. Keeping balance during the meeting is necessary so that everyone’s voice can be heard and not attacked. He or she must be prepared to guide the meeting with a plan and structure.

There are also a few things, however, that can lead to a facilitator’s downfall or discredibility.

Allowing people to run over each other
Forgetting to verify group’s decision
Showing a lack of active listening
Pushing his/her own opinions
Ridiculing ideas and options
Demonstrating no assertiveness
Discussing a topic too long
Making jokes on very serious topics

Read this great article by Keith Mathis for PM Hut.
Successful-facilitation

History of Project Management

2011-06-06T21:17:00.000-07:00

An interesting read by Merry Barron and Andrew R. Barron for PM Hut.

Could the Great Wall of China, the pyramids, or Stonehenge have been built without project management? It is possible to say that the concept of project management has been around since the beginning of history. It has enabled leaders to plan bold and massive projects and manage funding, materials and labor within a designated time frame.

Project management in its present form began to take root a few decades ago. In the early 1960s, industrial and business organizations began to understand the benefits of organizing work around projects. They understood the critical need to communicate and integrate work across multiple departments and professions.

The Project Management Institute (PMI) was founded in 1969 by five volunteers. Their initial goal was to establish an organization where members could share their experiences in project management and to discuss issues. Today, PMI is a non-profit project management professional association and the most widely recognized organization in terms of promoting project management best practices. PMI was formed to serve the interests of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects from the software to the construction industry. PMI first began offering the PMP certification exam in 1984. Although it took a while for people to take notice, now more than 260,000 individuals around the world hold the PMP designation.

Read the full article at:
History-of-project-management

Windows 8 looks impressive

2011-06-05T23:40:00.000-07:00

I changed to Ubuntu Linux over a year ago, and running on Ubuntu 11.04 at the moment. I just took a look at the new Windows 8 and it looks pretty impressive.

Avoid the Agile Logjam

2011-06-02T19:26:00.000-07:00

Bill Krebs looks into the importance of team dynamics and team commitment as a key success factor in Agile oriented projects in his article for Voices on Project Management.

Not all Agile teams are created equal.

Some commit to their work and complete requirements throughout -- not just at the end.

Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all.

What makes these teams different?

Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more.

Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action.

One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another.

If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned.

Stop Scope Creep from running away with your Project

2011-05-29T20:37:00.000-07:00

Duncan Haughey for Projectsmart, discusses causes and solutions to prevent scope creep from ruining your project.

Scope creep is one of the most common reasons projects run over budget and deliver late. Often done with the best intentions, changes to scope during a project are a negative event best avoided.

Most project managers have experienced a case where the customer asks for something outside the scope agreed and expects it included at no extra cost. In fact, they're probably acting as if it's always been in scope.

Defining the boundaries of a project is difficult, but without a clear definition you're heading for problems.

To summarise, ensure you set expectations correctly at the beginning of a project, working closely with the users to define clearly what is in and out of scope. Record it in the project initiation document. However, don't assume the customer will read and understand this document. Spend time with the customer to walk them through it and ensure they understand and agree the scope. Don't continue without a firm agreement.

Often it's not possible to avoid increasing scope during a project, especially if there is a sound business reason to do so. However, it must be managed properly. Design a change control process to ensure all changes are properly documented, considered, approved and resourced. Note: Where budget and time are increased with scope, the change is not usually considered scope creep.

Alternatively, you may wish to prevent changes being added piecemeal during the project and may decide to document them for a later phase. This allows the agreed phase to be delivered on time and budget, and the changes managed and resourced separately.

If you consider that only 32% ¹ of all projects fully succeed; then you're better-off spending your time delivering the requirements agreed at the beginning of the project, and avoiding gold plating.

Scope creep causes many project failures; by taking a few simple measures you can make sure it doesn't affect your projects.

Read the full article at:
Stop-scope-creep-running-away-with-your-project.html

Can Agile work with CRM?

2011-05-27T23:49:00.000-07:00

One challenge is wasting time treating each little sequential task (e.g. in Salesforce setting up validation rules, roles, field level security) as a separate story, requiring MORE time documenting things in a tool like Pivotal Tracker, then actually performing the tasks themselves. Because there are many sequential tasks with CRM. So many that documenting as individual stories takes an excessive amount of time, thus hindering rather than helping progress. What happens is when you apply true Agile, I’m finding, is that organizations STILL get hung up in too much PROCESS and DOCUMENTATION especially with new Agile teams, which almost all Salesforce CRM teams are. And what does the Manifesto say about a little concept about less documenting, more deliverables, less process, more collaboration, don’t get hung up on tools??? Right??? It’s important to stick to the principles we all live by, but with CRM, allow for flexibility in order to keep things moving effectively.

Read this excellent article by Tommy Ball for AgileScout:
Agile-and-CRM/

Project Failure: Cobb's Paradox

2011-05-27T09:06:00.000-07:00

Cobb’s Paradox states, “We know why projects fail; we know how to prevent their failure – so why do they still fail?”. PMI has recently published its latest Pulse of the Profession survey which shows some improvements on the 2008 and 2006 results but not much. Nearly half the projects surveyed in 2010 still failed to meet time and cost targets.

However, the PMI survey did highlight a stark difference between high performing organizations with a better than 80% success rate, and low performing organizations with a greater than 40% fail rate. And, the survey also clearly showed the processes typically used by the high performing organizations (and ignored by low performing organizations) are straightforward to implement and use; they include:

Using standardized project management processes.
Establishing a process to mature project, program and portfolio management practices.
Using a process to increase project management competency.
Employing qualified project management

So, given the tools are available, the knowledge is available, and the value has been consistently demonstrated; why are organizations still prepared to squander $millions on failed projects rather than investing a fraction of that amount in simple systems that can significantly improve the value they deliver to their stakeholders?

Read full article by Lynda Bourne for PM Hut:
Project-failure-cobbs-paradox

Project Estimation: Two Conflicting Trends

2011-05-27T08:58:00.000-07:00

In a number of organizations I have noticed two conflicting trends:

Organizations want business cases produced earlier (to prevent wastage of funds)
Organizations want increased estimation accuracy – typically ± 10%.

While the objectives are totally understandable, they are unrealistic.

If you insist on a business case too early in the project life-cycle you incur a high level of uncertainty — there are many things that you don’t know or don’t know well enough to accurately estimate. Often business cases are generated based on “high level requirements” – but, as we all know, the devil is in the detail and when the ‘detailed requirements’ are later defined they will often blow the budget.

We need to remember what we’re trying to achieve – ie not waste money, not allocate money to poor projects (however you want to define that) and not have big cost blow-outs. Bringing the business case forward and insisting on greater accuracy will not achieve this.
Instead, what you need to do is…

Recognize that there are ’sunk’ funds, ‘at risk’ funds and ‘total’ funds.
- Sunk funds are the expenditure to date – this money has gone whatever happens in the future. It may be painful, but it is not recoverable.
- At risk funds are the expenditure that you’ll lose if you invest in the next stage and then cancel the project. While you want to minimize ‘at risk’ funds, you also want to invest enough to see if the project will be valuable and viable on a reliable basis.
- Total funds are the total expenditure to the end of the project and are only at risk when they’re allocated and then spent. However great the total funds are, they are not at risk until you put them at risk. Better to spend, say, $5m determining the true value and cost of a project than, say, $500K to generate a baseless business case that later explodes in cost or implodes in value.
Recognize that the level of uncertainty is high until the requirements are known and the design agreed. Up until then the level of uncertainty is certainly above 10%.
The progressive questions a project needs to answer (as cheaply as practical) are:
1. Is the idea/concept relevant?
2. Is the project likely to be valuable and viable?
3. Can we afford it?
4. Can we deliver it?
5. Do we have the capacity to deliver it?
6. Is this the best use of our resources now?
As soon as any question is failed the project should be stopped and any remaining funding reallocated to other initiatives. The early evaluation process should, therefore, be focused on answering these six questions at minimum cost rather than insisting on early but unrealistic certainty.
Ruthlessly review projects/ideas/initiatives to see how they are faring against the six questions – and stopping any that fail as quickly as possible.
Along the way there will still be areas where you won’t know the answer yet – and this then needs to become the focus of the next stage of the project.

By the time you get to the final business case stage you should have no unknowns. Then you can have an estimate ± 10% and rely on it.
Accuracy demands in the face of reality is not a useful approach.

Article by Jed Simms for PM Hut.

Rework will Happen

2011-05-23T20:26:00.000-07:00

Excellent article by Michael Greer for PM Hut:

How to Design a Project with Rework Opportunities Built In

The following process will guide you through the process of designing a project plan with plenty of rework built in.

Assemble all project documentation you’ve created so far, including the stakeholder-approved Project Scope Statement, WBS (work breakdown structure), technical specifications, proposals, and so on.
Assemble the core project team and as many stakeholders as possible.
Conduct a brainstorming session in which the core project team and stakeholders do the following:
1. Examine each specific deliverable that must be created. (Refer to your WBS… )
2. List the specific tasks that must be performed to cause that deliverable to evolve from rough idea to finished product. (Use yellow stickies, flip charts, white boards, mind mapping methodology and other tools of brainstorming you like.)
3. Incorporate plenty of opportunities for stakeholders to review work products in small increments, as they are evolving. So, for example, if you are writing a report, don’t wait until you’re finished to share it with reviewers. Instead, share (and get feedback and make revisions to) an outline first and then a rough draft, before you spend your time finalizing and polishing the report. Specifically, insert as many “create, share, feedback, revise” cycles into your task list as possible. This will help prevent unplanned rework (and blown schedules from having stakeholders reject your deliverables!) by building opportunities for review and revision into your plan.
4. Combine and organize the list of tasks/activities into broad collections of related tasks or phases.
5. Create a network diagram (flow chart) showing the sequence and flow of all project tasks, activities, and phases. (See Sample Network Diagram, below.)
Polish and finalize the network diagram and task list.
Circulate the network diagram and task list to appropriate stakeholders/sponsor and get formal approval (i.e., sign-off).

Never Build More Than You Want to Revise

The spirit of the diagram above is this: Never build more than you want to spend time revising. That is, don’t risk hours of work in the “wrong” direction. Get feedback early and make adjustments early, then repeat — a little at a time, in small increments.

Read the full article at:

Rework-will-happen

Top 10 Procurement Risks - Tender Preparation

2011-05-23T20:17:00.000-07:00

Responding to RFTs (requests for tenders) can be risky, given that your tender response is a legal offer and you may be bound to the terms within it, if the client accepts it. Responding to a complex tender can also be very time-consuming, tying up substantial company resources for significant periods of time.

Top 10 risks

Below is a list of potential risks that should be assessed when responding to Requests for Quote or Tenders. These risks are generally the same as those you would identify for any building and construction project:

What constitutes a breach of contract and what is the resultant impact. Will a breach trigger termination, or will it require make good or rectification at your own cost? Can you terminate the contract or can it only be done by the client?
Delays caused by circumstances outside the builder’s control, such as; delivery delays that delay project completion, subsequent delays in progress payments, labor shortages, weather. Are you liable for any delays and what is the impact of this liability?
Exposure through clauses that work against the building organization, such as clauses that hold the builder responsible for circumstances outside their control.
Disputes over payments, either payments from the client to your organization or payment from your organization to subcontractors. Assess your cash flow to ensure that you can make payments to subcontractors even if you haven’t been paid by the client for a particular milestone.
Incorrect labor or materials costs, or miscalculations in any figures given. Have you added any budget or materials contingency?
Inappropriate funding levels and funding shortfalls for the project, resulting in a suspension or cancellation of the project or renegotiation of terms and conditions during the project.
Industrial disputes through misunderstandings on-site or through overt action.
Risk of default or non-performance of one or more of the key players, including the client, the builder and subcontractors.
Ignoring risk and failing to plan for it.
Positive risks. Risk is usually seen in a negative light, but some risks are positive and can be seen as an opportunity to enhance procurement objectives. These can include currency fluctuations and even proposed changes to legislation or regulations which could simplify compliance requirements and therefore reduce the overall cost of the contract.

Get more in this excellent article by Micheal L. Young for PM Hut.
Top-10-procurement-risks-tender-preparation

Nine Successful Keys to Delegation in Project Management

2011-05-23T20:06:00.000-07:00

Are we doing to much delegation in project to an extent that we are far too relaxed, or are we not delegating enough for fear that the project may not meet deadlines? Fred Morgan addresses this in an article for PM Hut.

Successful delegation is crucial to successful project management. Many people involved as leaders in project management are, however, afraid of delegation. They fear that if they delegate, the work won’t be done properly. Deadlines won’t be met. They cannot trust collaboration and teamwork to others; they have to do most things themselves and directly oversee the rest.

It is the delegation itself that must be done properly, however. Project management depends upon delegation simply because of the law of the division of labor: one person or team focused on one or two specific task(s) is more efficient and more productive than one person trying to juggle multiple tasks. One cannot be all things to a project or a business. As far as successful collaboration and teamwork go, these elements take care of themselves from an “emergent properties” perspective once delegation is done properly. The more laissez-faire project management is, the better. That manager is best who manages least.

Read Morgan's full article at:
Nine-keys-to-successful-delegation-in-project-management

Chromebooks : Added Choice

2011-05-16T21:04:00.000-07:00

Chromebooks has not yet seen the light of day and the doom-sayers are already having a field day. As with many new products that see the light of day, much time is spent to predict why it would be a failure. For eg. the iPhone 4 antennae debacle, Linux vs Microsoft vs Apple, Bing vs Google vs Yahoo etc. In all instances the underdogs has gained considerable marketshare and can boost on relative success.

Chromebooks offers a new dimension to computing and all realistic reasons may paint a grim future. But as with all articles that offer an opinion, the writer may have some bias. To assume that Google took on this venture on one assumption that everyone supposedly hates Microsoft is a bit far fetched. Google would not have been the number one brand, until recently surpassed by Apple, with a narrow-minded approach to new business. Chromebooks will be entering a huge market where product sales are driven by choice. The way it is priced, it is not too far fetched too assume that users will purchase it just for the sake of trying it out. It goes without saying that cloud computing does offer security challenges, but so does security in the conventional organization environment.

The challenge for Google lies herein, to drive the message that no additional hardware is needed to backup files, because documents will be saved in the cloud. Yes, hacking is a risk in the cloud, but organization server hacking is the order of the day too. No-one is immune to hacking. But are hackers really interested in personal files of the average user? I think not.

Facebook is an example of user trends to not protect their personal data by sharing personal data on personal pages and accepting third party applications that may divulge personal information. This trend suggests that the average user, whom will find the Chromebook affordable, talks about security, but does not entirely walk the talk. Wanting to be ahead of the pack and knowledgeable on the latest technology will be the winner at the end of the day. It is for that reason that I am giving the Chromebook a chance.

Broadband internet connectivity may offer increased opportunity for Chromebooks to compete in Singapore(96%), Hong Kong(99%), South Korea(97%), Switzerland(90%), Luxembourg(99%), Norway(84%), and Denmark(82%).

Chromebooks may surpass all expectations. I believe it will!

Please share your views.

My article is a response to an article by Mark Elgan for Computerworld:
Elgan_Why_Chromebooks_will_fail

Thoughts on Agile Planning

2011-05-09T21:08:00.000-07:00

Great article on Agile Planning by Mike Cottmeyer for LeadingAgile, posted on Project File.

Agile Math

The basic math of team based agile is pretty simple. You can slice it several ways, but at the end of the day, one of these three basic formulas has to hold true. It’s all about time, cost, and scope… you get to decide which two constraints you want to lock, but then you have to derive the third.

1. backlog size / velocity = duration
2. duration * velocity = backlog size
3. backlog size / duration = velocity

I generally suggest that agile is all about fixing time and cost, and deriving scope… but it doesn’t have to be that way. Feel free to derive time based on a fixed backlog and known velocity. You can even derive a planning velocity based on fixed scope and time. This one is the most risky, so be prepared to measure, adjust, and negotiate as the plan unfolds.

Limiting WIP

But here is the rub… when a team has too much work to do, and not enough time to do it, there is a cognitive dissonance between the messages of agile and what they see on the ground. We can say all day long that the PO gets to decide the “what” and the team gets to decide “how” and “how much”… but if management is fixing all three variables, the team isn’t going to buy in.

Rushing the Backlog

Generally, here is what I ask from management out of the gate… give us three sprints to help the team come up with a backlog and establish a velocity, afterwards we’ll see what we have and decide how to proceed further. We’ll start by doing just enough backlog planning to identify a sprint or two worth of work, and get the team working to establish a velocity.

While the team begins work to establish their velocity, the PO aggressively moves to create the backlog. Almost never do I see a PO that can create a backlog all by themselves. Very often we need Product Managers, Architects, and Analysts to paint the complete picture. More often than not, I’ll ask these folks to work full time for as long as takes to get the backlog together.

I’ve got one PO team that has been at it 8 weeks just to get ahead of the team, and define the release. Initially the PO team is focused on feeding the teams high value, high risk stories… but as the backlog emerges we start rounding out the app. If all goes well, after several sprints we have a decent idea of what we have to build and the rate at which the team can complete the work.
At that point, we apply one of our three formulas, baseline the plan, and go.

Emergence or Convergence

How far ahead of the team you need to be largely depends on your business goals for the release. If you are highly uncertain about what you need to build, smaller backlogs are probably better, and the release planning process can be more nimble. Trying to predict stuff you just don’t know is waste. In this case, agile is helping support an emergent outcome.

Not all companies are going for an emergent outcome… some want stability and predictability. In these cases, the PO team needs to plan further ahead of the team and adjust as the product is developed. The better we know where we are going, and what it is going to take to get there, the further out we can plan the backlog, and the more certain we can be about outcomes. Here agile is supporting a convergent outcome with focus on risk reduction and predictability.

One of the biggest problems I see with teams new to agile, is that they act as if they are going for stability and predictability, when their product requires an emergent approach. Either requirements are not well understood or because of high technical risk or a ton of unknowns around how to implement. Either way, you have to act as if the project is emergent until you gain enough knowledge to establish a more predictable plan.

Not Knowing What You Don’t Know

I’ve met a few teams lately where everyone is new and unfamiliar with the product and the code base. How do you set a schedule in this environment? The short answer is… you don’t. It’s okay not to know, but it’s not okay not to know forever. In this case, you better have a plan to get it figured out fast… It’s not reasonable to indefinitely ask the business to invest with no strategy for getting to done.

Project Management Authority is Earned not Given

2011-05-07T20:29:00.000-07:00

Leading by example generally earns respect and authority to the person that exercises it. This is by no means any different in project management as seen in the article by Dan Vickers and Kurt Finch for PM Hut.

For project managers, the support of their team is critical for completing projects successfully. Yet, a team’s respect cannot simply be assigned like a task. Acquiring and executing project authority with the support of a full project team demands careful and skilled execution.

Project leadership requires a humble yet assertive persona, capable of taking charge when needed and delegating authority wherever possible. A project manager must develop their own skills and lead with principles. Doing so will certainly encourage team loyalty. If a project manager simply presumes authority, they will never earn the backing of their team. This is an ongoing practice that should drive the way a project manager carries himself and shapes how he interacts with others.

Lead by Example

A project manager can’t just “talk the talk” but has to also “walk the walk”. If not, she will lose all credibility. In order for a project manager to earn their team’s respect, they must wholeheartedly support their own decisions and back them up with actions.

The most effective way to earn authority is to be a project leader that others want to follow. Be on time. Be kind and considerate. Be efficient with your tasks. Be organized. Be fair with others. Set an example for others to follow.
The project manager is a tricky position to navigate, yet just a few simple practices can enhance a project manager’s powers of persuasion and increase their influence enough to achieve tremendous things. A project manager should always remain cognizant of the fact that they aren’t the boss; they are a leader of a team that will be inspired to follow or struggle at every step along the way. The process will be made much easier by being kind, respectful, and benevolent in decision-making.

Read the full article:
Project-management-authority-is-earned-not-given

Tips and Tricks for Ubuntu after Installation

2011-05-03T21:59:00.000-07:00

Click on the link below and enjoy the read.

Tips and Tricks for Ubuntu after Installation

Seven Deadly Project Manager Sins

2011-05-03T21:30:00.000-07:00

In spite of an increased focus on competency in PM conferences, journals and online knowledge sources, organizations continue to experience project failures at the hands of incapable PMs.
Identifying common negative behaviors that can contribute to these failures might be the first step towards recovery:

Communication imbalance – communication consumes a significant percentage of a PM’s time so one would assume that this is a competency that even poor PMs would excel at. Unfortunately, some PMs treat knowledge & information like power – sharing it with those they wish to curry favor with, and leaving everyone else in the dark. Other PMs have a case of verbal “Montezuma’s revenge” – this is equally bad as stakeholders are unsure what information is critical and what is minutiae.
Neglecting stakeholders – Project Managers can get tunnel-vision by focusing purely on their direct customer or sponsor. While this individual might be the one signing deliverable acceptance forms and evaluating your performance, a good PM needs to practice 360 degree management – sponsor, stakeholders & team.
Inaccurate or incomplete project control books – It doesn’t matter how heavy or light your PM methodology is (or even if you organization doesn’t have one). There’s a basic set of project data that should be kept current so to facilitate project tracking, control, monitoring and (if you win the lottery) transition. Having an out-of-date schedule is worse than having no schedule at all – at least a stakeholder doesn’t draw any wrong conclusions from a non-existent schedule.
Ignoring conflict – Conflict is a natural occurrence on most projects but accidental PMs are often unused to managing interpersonal conflicts and might be tempted to ignore them in the hopes that the situation will resolve itself.
Jettisoning risk management – If a PM happens to be aware of good project management risk practices, they might not have the intestinal fortitude to “sell” the necessity for these practices to their sponsor, stakeholders or team. Under pressure to deliver, if they skip risk management, they’ll at least have the opportunity to improve their fire-fighting skills!
A blind focus on the triple constraint – While scope, schedule & cost constraints are important, a PM might ignore the fact that a project has to deliver business value to avoid “the operation was a success, but the patient died” syndrome. Poor PMs are less likely to ask questions such as “Is this deliverable necessary to the end result”, “Are we gold-plating” or “Is this project still of value to the organization”?
Poor assumptions management – Projects possess uncertainty and to try to reduce this uncertainty, we make assumptions. A good PM will log critical assumptions, share them with the overall project team, attempt to validate them proactively, and use them as one of the inputs into risk identification. A bad PM will forget the assumptions shortly after they were made…

By no means is this list exhaustive.

Article by Kiron D. Bondale for PM Hut.

Shuttleworth on Ubuntu 11.04 Linux and Unity

2011-05-01T21:51:00.000-07:00

I installed to Ubuntu 11.4 Unity alongside 10.04, a couple of days ago. My first impression of the GNOME 3 interface was one of total dislike. I am willing to give it a couple of days to grow on me.

Below is Mark Shuttleworth's take on Ubuntu 11.04:

Ubuntu 11.04 has been out for a few days now and while, generally speaking, I like Ubuntuâs new Unity interface, I know some people really dislike it. So, who better to explain why Unity looks and works the way it does than Mark Shuttleworth, founder of Ubuntu and the company behind it, Canonical?
Shuttleworth opened by saying that the main point of Ubuntu 11.04 with Unity was âto bring the joys and freedoms and innovation and performance and security that have always been part of the Linux platform, to a consumer audience.

Read the full article at:
Shuttleworth on Ubuntu 11.04 Linux and Unity

PMP Certification: Is it worth it?

2011-05-01T20:43:00.000-07:00

Pam Stanton's verdict:

In summary, here’s how I see it. Getting a PMP certification won’t hurt you, and it may expose you to some useful tools and ways to organize projects. It won’t, however, make you a great project manager—that you’ll have to earn through blood, sweat, and tears, and hopefully some laughter.

What does hurt all of us as a profession is the misconception that a PMP certification is an assurance of competence, and that’s where I’m passionately opposed. I seek to drive balance and visibility to the real skills that make or break a project manager, which is the emotional intelligence to know which tool to use at the right time, including a deep respect and appreciation for human behavior and group dynamics. As I repeat in my book and speeches: Human behavior is not a work breakdown structure, and methodology alone will not get you there.

My Verdict:

The PMP Certification has great value for non-certified Project Manager's coming from so-called third world economy into a first world economy. Although project management methodologies, concepts, and project execution is the same globally, the PMP certification is undoubtedly a great certification to consolidate years of project management experience with a certification that is well sought after by many international organizations.

Read the full article by Pam Stanton for PM Hut and share your views:
Pmp-certification-is-it-worth-it

How short can your Program Charters be?

2011-05-01T20:03:00.000-07:00

Great article by Johanna Rothman for PM Hut.

A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information.
But what do you really need in a charter? Too big a charter and it’s tempting to fake your way through it. Too small a charter, or insufficient information, and it’s not worth the time you spend on it.

I’m not sure there’s a “Goldilocks” size for every program’s charter, but here’s my attempt:

The program vision. You need a vision or purpose so everyone knows where the product is headed. Depending on the size of the program, the projects that make up the program may need visions also, but you need to know you’re making a cell phone or a refrigerator.
Release criteria. You need to know what done means for the product so you know when you can release.

Can you write more? Sure. Do you need to? Maybe not. If you’re agile, definitely not, not for the charter. For example, lots of people like to try to discuss ROI (Return on Investment) in a charter. Well, I can lie with numbers, to make the numbers look any way I want them. ROI is a prediction that only starts once the program ends, so that’s not helping the people creating the product.
Remember, a charter is just enough to help you get started. It’s not supposed to be a book, or a thesis, or the reason for the program’s existence. It’s also not supposed to be one sentence, “We’re making a cell phone.” The charter provides everyone on the program the 50,000 foot view of what they are building and how they know it will be done.

Don’t shortchange your program charter, especially if you’re working on an agile program, and don’t overdo it.

Project Decisions

2011-05-01T19:54:00.000-07:00

During the life of any project, many decisions must be made. The number and importance of these decisions will depend on the size and complexity of the project, but it is safe to say that any project will have some decisions and managing these is a critical part of the project manager’s job. How you manage these decisions will depend on several factors: whether the decision is yours, whether it is a gating decision, or whether the decision would change the scope, schedule, or budget of the project.

Every decision made on your project comes with a “best before date”. Some “best before dates” are explicit and easily identifiable, others are implicit and require some sleuthing to determine. Your job is to identify the date, identify the decision makers, and then get the necessary information in their hands so they can meet the date. Keeping your eye on these keys to decision making will help your project deliver on time.

Read full article by Dave Nielsen for PM Hut:
Project-decisions

What are Agile Methodologies

2011-04-27T21:27:00.000-07:00

Todd Burton writes for PM Hut that, the first step to examine what has to be done to launch a lean startup. One of my colleagues noted that “lean startups are all about using project methodologies (agile) to increase agility & flexibility and to fully utilize open-source platforms to lower costs” [Jeong, 2011]. With the goal of launching a startup using offshore development, the question remained how do we develop a lean startup, yet with offshore (not opensource) development teams?

A logical beginning for me was to examine what exactly is an agile methodology? Understanding this will allow clarification and direction moving forward. This piece will outline common agile methodologies and their potential for launching a lean startup.

In order to better understand agile, I examined popular agile methodologies in today’s marketplace. This following section will outline the following methodologies; SCRUM, XP, RUP & RAD.

SCRUM SCRUM utilizes small teams to deliver increments of software using “sprints”. These sprints may last for 14-30 days, during which all parties strive to achieve a specific goal. Each day begins with a kick-off meeting to assure quality control. Martin Kearns, from IT firm Renewtek states “SCRUM enables developers to prioritize work based on actual business value…which then leads to regular returns on investment and improved communication channels to management and product owners” [Baltzan et al, 2010].
XP
XP (eXtreme Programming) utilizes small project phases that act as tollgates for a developer to proceed (i.e. phase X must be completed before phase Y). Its central focus is on the facilitation of planning, designing, coding and testing, and integrating these throughout each small project. XP stresses customer satisfaction and empowers project staff to change requirements instantly to accommodate customer demand. As XP relies on many parts making up a whole, successful teamwork is inherent in this methodology [Baltzan et al, 2010].
RUP
RUP (rational unified process) is a framework that breaks software development into four gates; inception, elaboration, construction and transition. Each gate has a list of deliverables that must be accepted by stakeholders before advancing to the next stage. Its focus is quickly adding or removing large chunks of reusable software to solve common problems [Baltzan et al, 2010].
RAD
Rapid Application Development, or RAD, is a methodology based on broad user involvement in prototype development to hasten the software development process. It utilizes iteration to collect changing business requirements while proactively involving software users in analysis, design and development. This methodology is often known for prototypes turning into final solutions [Baltzan et al, 2010].

Read the full article at:
What-are-agile-methodologies

Struggling to Define your Project Approach?

2011-04-27T21:17:00.000-07:00

It doesn’t seem that hard to define a project’s approach. It’s just a description of the project strategies for achieving the project objectives. Simply stated it’s the path the project team will take to get to the desired end result. Simple as it may be it still drives many project managers nuts, causing them to stare at a blank page, unable to articulate anything of value.
Three types of project managers struggle with defining their project’s approach:

Type 1: those who have always worked on projects of the kind.
Type 2: those who have worked on similar projects but the conditions of the current project are not at all the same.
Type 3: those who have never taken on a project of the kind, nor has their organization.

Read full article by Ben Snyder:
Struggling-to-define-your-project-approach

Agile - The new buzzword in Project Management

2011-04-21T23:16:00.000-07:00

Agile is popping up everywhere and taking prominence on many Project Management Blog's, websites, etc. Is Agile an extension of current project management principles, and/or a scientific approach to address how projects need to be performed?

According to Michael Hugos, "Given the demands of the real-time global economy, the future of both IT and business is clearly going to be a future where agility is central to success. And the kind of agility that delivers success is going to be composed of something new and something old. It will be a hybrid agility that delivers practical and pragmatic solutions to ever changing business needs."

Read the full article by Michael Hugos for CIO:
Hybrid_agile_moving_agile_development_to_the_next_level

20 Best Practices for Project Managers

2011-04-18T09:43:00.000-07:00

Hire the best, most experienced people you can.
Encourage team members to speak up and make themselves heard when they see something’s going wrong.
Do any menial work that’s needed to keep your team moving.
Know your project life cycle cold.
Continually sell the value of your project’s systematic, iterative life cycle to sponsors and stakeholders.
Don’t let your sponsors get out of making the tough decisions.
Always create some sort of blueprint, design, flowchart, system specifications, outline, or other detailed “on paper” description of your finished product before you build the real thing.
Make sure your sponsors provide or, at the very least, approve all the experts on the team.
Protect your project team members.
Fight for enough time to do things right.
Know when to give in.
Understand that the brain is a physical mechanism that needs to be rested to work properly.
Stay humble about your PM. And accept this in your heart: PM is overhead.
Step into the fear.
Be on the lookout for team members who are in pain and help them find ways to eliminate it.
Think of yourself as a switchboard.
Fight for what’s right.
Insist that the sponsor (customer) sign off and approve deliverables as they are evolving.
Develop a sense of humor and a “willful suspension of disbelief.”
Plan, plan, and re-plan.

By Michael Greer

The Product Champion, the Chief Engineer, and the Project Manager

2011-04-18T09:39:00.000-07:00

I enjoyed this article by Olve Maudal for PM Hut.

It's certainly good to have role clarification before a project takes off. The involvement of the three parties, mentioned in this article, are crucial in the initial project stages in setting up the project statement and project scope, determining the direction the project should take. In my opinion the role of Product Champion is high in the initiating and closing stages of the project. The role of Chief Engineer would be high in the initiating stage of the project and medium in the rest of project. Both the aforementioned roles will act in advisory capacity to the project. The role of Project Manager will be high throughout the project as to secure project success.

Read the full article at:
The-product-champion-the-chief-engineer-and-the-project-manager

OpenOffice.org to become OpenSource in every sense of the word

2011-04-16T22:59:00.000-07:00

This bold move by Oracle is music to the ears of the OpenSource community. The move will attract some of the brightest minds in the free software community and we may see some welcome additions to the OpenOffice software and/or, probably more than likely, the packaging of OpenOffice with other free software packages.

Steven Finch writes in Crenk:

Oracle has just announced that they intend to move OpenOffice.org to a purely community based open source project and no longer offer a commercial version.

“Given the breadth of interest in free personal productivity applications and the rapid evolution of personal computing technologies, we believe the OpenOffice.org project would be best managed by an organization focused on serving that broad constituency on a non-commercial basis,” said Edward Screven, Oracle’s Chief Corporate Architect. ”We intend to begin working immediately with community members to further the continued success of Open Office. Oracle will continue to strongly support the adoption of open standards-based document formats, such as the Open Document Format (ODF).”

Oracle has been a very closed company for some time, but they have also invested heavily in Linux and MySQL. It will be interesting to see if the community really jumps onto the OpenOffice bandwagon.

New trends in Project Management

2011-04-15T01:48:00.000-07:00

Is Agile and Scrum moving the barriers for projects updates , or is it an unnecessary inconvenience? The Project Management Institute is developing an Agile Certification.

According to the PMI website:

"Practitioners who are using Agile practices in their projects, or whose organizations are adopting Agile
approaches to project management, are good candidates for the PMI Agile Certification. By earning the
Agile certification, practitioners can:

Demonstrate to employers their level of professionalism in Agile practices of project management
Increase their professional versatility in both project management tools and techniques
Show they have the capacity to lead basic Agile project teams by holding a certification that is more credible than existing training-only or exam-only based offerings"

See discussion on Agile and Scrum:

7 Basic Principles of Effective Project Management

2011-04-14T00:33:00.000-07:00

Each Project Manager has his/her own idea of what is perceived is the most important skill in the project management profession. These may include leadership, communication, adaptability, people skills, patience, transparency, etc. These are all very important, but there should be a set or sets of principles that forms the basis for operating projects.

Hauke Borow lists and explains some of these principles in an article for PM Hut:

Project structure
Definition phase
Clear goals
Transparency about project status
Risk recognition
Managing project disturbances
Responsibility of the project manager

Read the full article at:
7-basic-principles-of-effective-project-management

Project Status Reporting

2011-04-12T00:37:00.000-07:00

Steve Hart concludes in PM Hut that a project status report should not be created with the view that it satisfies a requirement mandated by management, but rather a best practice that creates significant value for you, as the project manager, the core project team, and other stakeholders. Effective use of the project status report is one of the clear indicators that the project is “under control” during the execution phase of the project. On top of that, there will be no need for this conversation: “Hi, Peter. What’s happening? We need to talk about your TPS reports.”

Read full article at:

Project-management-foundations-project-status-reporting

Paypal is about to get a Bruising from Facebook and Square

2011-04-12T00:18:00.000-07:00

Paypal just cannot compete with Facebook and Square. Both Facebook and Square outsizes Paypal by far, and the latter will not be able to weather the storms in the payment market. Facebook's mere size is beyond belief which can do huge damage to Paypal's market share, once Facebook decides to vigorously pursue the online payment market. Facebook is a household phenomenon and with well thought through strategy to enter the payment market, and a public relations stint to back it up, will easily catch on to FB users because of the nature and position FB has taken in our lives. Well, unless by some strike of genius and luck, Paypal joins forces with Paypal, an unforeseen merger in my opinion.

Square's service offering of secure payment via credit card through mobile phones, amongst others, is in the right market with exponential growth potential to their existing 1 000 000(million) credit card processing payments per day. Like I said, it can only grow.

Ohad Samet writes an interesting article for Tech Crunch, discussing this topic:
Techcrunch.com/2011/04/09/paypal-facebook-square/