Archive for the ‘IT’ Category

So I got home today, and found a package at the front door by UPS. Its Christmas, and I order stuff online, so I thought nothing of it….Until I opened the box that is.

VMware’s Certification Team reached out to the people who hold VCDX Certification, and stated we should expect something later this year. We have gotten some nice shirts, stickers, and other do-dads that we all use. The VMware Team also said we should watch out, as we will have our expectations exceeded when we get this package.

Well, I forgot all about it, until I saw who the package was from. HUGE box, and I could not begin to imagine what was included, and it was sweet.

I recently received an email from an individual who is considering applying for, and defending for, his VMware Certified Design eXpert (VCDX) certification. It is a trying process where you submit a design for a solution to be implemented, document the process, its operations, and justify your choices throughout the design. Once you submit the design, and are approved, you are then invited to defend the design in front of a panel of those already certified. A trying process…it was for me anyway…

I have promised this individual that I would assist him, when he was ready with his design. It has been almost two years since we had that first conversation that I would assist him. He recently sent me this email (which I asked if I could publish). It shows what went on in his mind, and what sparked his renewed commitment to submitting his VCDX design. My hope in posting this online, is that other people will see it, relate to this in some way, and have confidence in themselves to tackle this certification if they feel they are ready.

If you do get something out of this, can relate in some way, or are encouraged by the content of the email posted below, PLEASE…. post a comment. It would mean a lot to those whom we do not yet know who may feel the same way….

Mark,
I missed yet another submission deadline last night, this one for October, 2012. The big difference this time was that I wasn’t sitting around “stirring ice cubes in my drink” watching the clock tick by. I was up until 3:00 AM furiously typing before I finally admitted that I didn’t have things ready to submit. I haven’t been that pissed at myself for a long time.

This whole process has left me with an unfamiliar feeling. I usually am very confident in myself, but for some reason I had a mental block against doing this design. I guess that my lack of ‘large’ customer design experience and a lack of ‘canned’ documentation had me thinking that it was to much for me to do on my own. I wasn’t concerned about my design skills, but more my documentation skills. As a result, I have had several restarts to the process I’ve spent more time ripping and replacing versions than I have actually producing content. For me, it wasn’t my game skills that were in question, but a lack of knowledge about the rules and field dimensions.

I’ve had a framework for what I wanted to do all along, but couldn’t grasp the structure. Was my documentation up to snuff? Would I be laughed at for submitting a design like that? The sheer number of pages was huge. I have never produced over 100 pages of documentation for a single project design. In my defense, I’ve never had a customer that has required that much work for a project. No need, no effort. I started at Acme Inc. 4 years ago as the 2nd engineer on staff. Within a month, I was the only guy there. I had no documentation or templates left to me other that a single SOW. Since that time, I have cobbled together all of the documentation at Acme Inc. myself. Right, wrong, or indifferent, it sprung from my head. Is it ‘industry standard’? I doubt that, seeing how I have not seen any other competitor documentation and have had nothing to compare it to.

Things changed this week. I built (yet again) another project template, trying to incorporate all elements into a viable framework, and started porting over some of my information. Then a strange thing happened. One of my twitter followers asked me to review his design, as he is defending this week in SF. I agreed, and he send me a copy. After reading his design and giving him feedback, all of my doubts faded away. I found several holes in his design that seemed really obvious, but apparently were not to him. Additionally, seeing his documentation framework gave me validation that I was on the right track, and that my ‘template’ was not only as good as his, but possibly better.

And more importantly… This was a design that had been accepted as a possible passing design and he was defending it! Clearly (in my mind) my design was better than his. My documentation framework was better than his. I know that my defense skills, presenting and defending to the panel, are better than his. Why was I doubting myself so much? I needed to get my ass in gear!

Well, long story short… and looking back at this, it isn’t a short email (sorry)… I have been cranking furiously on my design since Monday night. Several late nights later, I spend all yesterday trying to wrap things up and get it ready for the Midnight (Pacific) deadline for submission. Down to the wire, I finally had to stop at 3:10 AM and admit that I might have been able to submit the design, but wouldn’t have completed all of the accompanying documentation such as Delivery and Installation, Testing and Acceptance, and such. I would come up short yet again.

For the first time in the whole process, I was driven to complete. I disappointed myself by not closing the deal. I have nobody to blame but myself, and it took about 30-40 minutes of walking around the house alone for me to cool down enough to go to bed. This morning, I realized that I’m not really that upset about missing the deadline, because I will be ahead of the game for the next one in February 2013. I am ready, I focused, and I have a plan to complete.

Why am I sending this to you instead of packing to head to Boston in an hour? Because I want to say thank you for not giving up on me. All of the gentle (and not so gentle) nudges to get working on my design were appreciated. You have been there waiting for me to get on the ball and weren’t judging me. When I was ready, you would be there to help me on the path. I appreciate that you are there as a friend, advisor, and a mentor through this whole process.

I just wanted you to know that I’ve finally gotten my “Design Mojo” back and I’m ready to rock this thing. And I wanted to say thanks for being a friend through the whole thing. Catch you later tonight in San Francisco.

So I have decided to take this gabbs.com domain name, and start using it for consulting services. The changes will happen sometime in the next couple of months, and it will be for my personal exploits.

It will be tough to make sure I don’t compete with my current company, but we serve different types of clients, so I’m sure it won’t be too difficult….

Mistake No. 6: They lack up-to-date data about the status of projects.

Mistake No. 7: They ignore problems.

Mistake No. 8: They don’t take the time to define the scope of a project.

Mistake No. 9: They fail to see the dependencies between projects.

Mistake No. 10: They don’t consider Murphy’s Law.

Mistake No. 11: They give short shrift to change management.

Mistake No. 12: Project schedules are incomplete.

Mistake No. 13: IT doesn’t push back on unreasonable deadlines.

Mistake No. 14: They don’t communicate well with project sponsors and stakeholders.

– Meridith Levinson, CIO

July 23, 2008

It’s no wonder only 29 percent of IT projects are completed successfully, according to The Standish Group. Project management consultants and software providers say they see IT departments making the same project management mistakes over and over: IT groups don’t follow standard project management processes. They don’t have the right staff working on projects. They don’t assess the risks that could imperil their projects or determine ways to mitigate those risks. The list of mistakes unrolls like a ball of yarn.

MORE ON PROJECT MANAGEMENT

How To Spot a Failing Project

ABC: An Introduction to IT Project Management

When Project Failure Is Not an Option

How to Create a PMO and Select PM Software

Most of the project management mistakes IT departments make boil down to either a lack of adequate planning or breakdowns in communication (either among the project team or between the project team and the project sponsors). These mistakes can be fatal. They can also be avoided. And who better to point out the most common project management mistakes than project management vendors and consultants. (They also suggest ways to avoid them.)

The following list of the 14 most common project management mistakes ought to help you pinpoint where your projects are going wrong and measures you can take to improve them. The upside of avoiding these most common project management pitfalls is tremendous. Not only will your project success rate increase, you’ll also improve satisfaction among internal customers, IT’s stock inside the organization will increase in value, and the business will benefit from systems that make them more competitive that get delivered on time and on budget.

Staffing Mistakes

Mistake No. 1: Projects lack the right resources with the right skills.

Impact: Proper project staffing is critical, yet improperly allocating resources tops the list of most common project management mistakes. Not having the right people on a project can kill it. “The key to getting a project successfully accomplished is getting the right people with the right skills,” says Joel Koppelman, CEO of project management software vendor Primavera. “All the planning in the world won’t overcome an insufficiency of talent.”

Solution: IT and project managers need full visibility into the skills and workloads of all of their resources, including consultants, contractors and outsourcers, who often get left out of skills assessments even though they’re doing a “huge” proportion of work, says Koppelman. Project management software can provide such visibility into everyone’s skills and workloads.

Once IT and project managers know who’s doing what, they have to figure out how to allocate resources across myriad projects and day-to-day work.

“There are all kinds of organizational models,” says Richard Scannell, co-founder of IT infrastructure consultancy GlassHouse Technologies. “I’ve never seen anything that works well. There’s no easy answer [to the resource allocation question].”

You just have to try synchronizing people and projects as best you can, says Koppelman, adding that one potential solution is to appoint a resource manager who’s responsible for figuring out who will be assigned to each project and for ensuring there’s a fair allocation of talent across projects.

Scannell suggests setting up “tiger teams” where people get taken out of their traditional job responsibility for a year or more to work on a specific project. Ken Cheney, director of HP Software’s PPM Center, recommends assigning resources at a project level as opposed to a specific task level, which he says is much more arduous.

If you’re still hard-pressed to adequately staff projects, you may be able to free up resources by cancelling a “discretionary” project (e.g. one that isn’t tightly tied to the business strategy), says Cheney. He suggests looking at your entire portfolio of projects your IT staff is working on to identify ones that aren’t mission-critical. “By stopping those projects and reallocating resources to projects that will have the biggest impact, the organization as a whole can be much more successful,” he says.

Mistake No. 2: Projects lack experienced project managers.

Impact: Projects can quickly grow out of control without a savvy project manager at the helm.

Solution: Hire project managers with certifications and the finesse required to manage stakeholders. Matthew Strazza, vice president of services (North America) for CA, says good project managers have to have strong soft skills. They need to know how to facilitate meetings, manage risk and handle a variety of different stakeholders—the business people who are looking for functionality, the IT people who care about security, and the financial people who are worried about the budget.

“If you’re not addressing the financials, managing the budget on a week-to-week basis and notifying the client of any change, you can get into trouble pretty quickly,” says Strazza.

Good project managers also need to possess technical expertise in whatever technology is being deployed, he adds.

Impact: This is the second of the most common project management mistakes. Lack of methodology increases the risk that tasks related to the project will fall through the cracks, that projects will have to be re-worked, and ultimately that a project won’t be completed on time or on budget.

Solution: A project management methodology helps you tackle projects efficiently and makes you aware of all the activities involved in the execution of a project.

“Having in place a baseline of standards and methodologies will remove a lot of the risk associated with IT projects,” says HP’s Cheney.

Douglas Clark, CEO of Métier, a provider of project portfolio management solutions, recommends establishing repeatable processes for scoping, scheduling, allocating resources and communicating with stakeholders. “Those are the things you want to get a handle on first because they would probably give you the biggest payoff,” he says.

Mistake No. 4: IT gets hamstrung by too much process.

Impact: Too much process makes the project team inflexible, and their inflexibility frustrates stakeholders.

Fumi Kondo, managing director of NYC-based consultancy Intellilink Solutions, once observed an exchange between a software developer and a project manager where the developer told the project manager that he could add extra features to an application with no additional effort. The project manager told the developer not to add the extra features because users hadn’t asked for them. “My response would have been, ‘Go to the users and see if those features are useful,’” says Kondo. “I see nothing wrong with over-delivering if it doesn’t impact the budget or the schedule.”

Solution: Be flexible and communicate with project sponsors and stakeholders.

Mistake No. 5: They don’t track changes to the scope of the project.

Implication: The budget for the project explodes. So does the timeline.

Solution: CA’s Strazza recommends following a formal change request process: The individual requesting the change in scope (e.g. additional features or functionality) needs to explain the specific changes on a change-in-scope document, and the project manager needs to determine how that request will impact the budget and timeline. The project sponsor has to sign off on the change-in-scope request.

Mistake No. 6: They lack up-to-date data about the status of projects.

Impact: You can’t manage what you can’t measure, as Peter Drucker would say. Nor can you coordinate resources or react to changes in scope, says HP’s Cheney.

Solution: Software.

Mistake No. 7: They ignore problems.

Impact: Problems don’t solve themselves. They fester the longer you ignore them and ultimately compound the cost of the project.

Solution: “If you do something wrong, it’s about how well you fix it,” says GlassHouse Technologies’ Scannell. “Most people batten down the hatches and look up in the month. Understanding when you’re starting to fail and quickly being able to engage as many stakeholders as possible to fix it is critical.”

Planning Mistakes

Mistake No. 8: They don’t take the time to define the scope of a project.

Impact: If a project’s scope isn’t well-defined by the business and IT up front, the project can end up ballooning like Friends actor Matthew Perry in the sitcom’s later seasons. What’s more, IT lacks the clarity and direction it needs to complete the project on time and on budget and meet the business’s expectations.

Solution: Ill-defined projects are best served by a business case and a scoping exercise, says Intellilink Solutions’ Kondo.

Mistake No. 9: They fail to see the dependencies between projects.

Impact: Projects don’t happen in isolation. They’re often dependant on other projects going on at the same time. When project managers fail to see the dependencies between projects—such as staff assigned to one project are needed on another&mdashh;projects get held up. Such slowdowns can have a ripple effect on all projects.

Solution: Take dependencies into account during project planning, says Métier’s Clark. Talking with stakeholders and diagramming the project can help uncover dependencies.

Mistake No. 10: They don’t consider Murphy’s Law.

Impact: Stuff happens, and IT gets surprised by it. Consequently, the project goes off-track while IT tries to clean up a mess it didn’t anticipate.

GlassHouse Technologies’ Scannell recalls a company in the U.K. that his firm acquired, that was moving its mainframe to a new data center. The IT group devoted an entire Saturday to taking down the mainframe so that they could move it to the new data center the next day, he says. While the IT staff were en route to the new data center with the mainframe on Sunday, they ran into a gay pride parade, and they couldn’t reach their destination due to roads blocked off for the parade. They had to drive back to the original data center and put Humpty Dumpty back together again. The lack of planning caused the IT staffers to do more work than was necessary.

Solution: Perform a risk assessment as part of the project planning. With your team, brainstorm what could happen to slow or derail the project, to make it go over budget, or to prevent you from delivering the expected requirements. Then figure out ways you can mitigate those risks, says Primavera CEO Koppelman. “If they sit down and think about those risks, they’ll come up with a pretty good list,” he says. “This exercise doesn’t take a long time, and it’s enormously helpful in understanding the soft spots in a project before it even gets underway.”

Mistake No. 11: They give short shrift to change management.

Impact: All the time, money and hard work that went into delivering a new IT-enabled capability can be for naught if users don’t adopt the new technology.

Solution: Spend time up front during the project planning phase to consider where resistance to a project will manifest itself and ways to address it, says Métier’s Clark. Identify the stakeholders whose jobs will be impacted by the new capability, adds Intellilink Solutions’ Kondo, and plan how you’ll communicate changes to their processes and workflows with them. Not all of the changes will be negative.

Mistake No. 12: Project schedules are incomplete.

Impact: Project team members don’t know what is due when, which makes completing the project on time a challenge.

Solution: Clark says a quick way to come up with a schedule for a project is to determine all the activities involved in getting the project done (e.g. scoping, getting requirements, testing and implementing) and then attaching due dates to those activities based on the deadline for the project. Project management software can also help create schedules.

Communication Problems

Mistake No. 13: IT doesn’t push back on unreasonable deadlines.

Impact: IT sets itself up to fail and gets a reputation for not being able to deliver projects on time.

Clark says IT departments will scramble to accommodate project deadlines set by the CEO. But tampering with dependencies and with the plan only creates more problems that make delivering the project on time even more difficult, he says.

Solution: IT management has to explain to the CEO what it’s going to take to meet that deadline in terms of cost and resources and has to get the CEO to choose between cost, scope and schedule, says Clark.

Mistake No. 14: They don’t communicate well with project sponsors and stakeholders.

Impact: IT fails to deliver the expected requirements.

Solution: Project communications need to be catered to the audience, says Kondo. She sees misunderstandings about the scope of a project or a systems’ requirements arise when IT departments hand over a spreadsheet to the business with thousands of lines describing the systems’ functionality and specs. Because the business owners don’t have time to look over such detailed technical documents, they ignore them.

“One side is communicating, but in a language the other side can’t understand,” says Kondo. “Then IT gets frustrated and they say, ‘We described this to them. How come this isn’t what they want?’” (Business analysts play a critical role as the liaisons between users and IT.)

Kondo recommends giving every stakeholder who will be impacted or involved in the project on the business side a high-level overview of the entire project, from design to rollout. The overview should highlight the activities that require interaction with the business and should explain why the business is needed, she says.

In general, IT needs to put more effort into educating the business about the steps involved in executing a project, says Kondo.

“If you have an open dialog about what’s needed, what you’re really delivering, and you have fluidity built into the process, the budget and scope becomes a dialog so if you go over budget, it’s not necessarily a failure,” she says.

Kondo’s firm once worked with a client that was deploying a financial system and whose employees had never been involved in a large system implementation before. When design of the system was complete and Intellilink was beginning to plan for testing, Intellilink explained to the employees why testing was important.

“We told them about different kinds of testing and what they did and didn’t need to be involved in. We talked about why we needed user input, what kind of input we’d need and how much time it required,” says Kondo. “That gave people an idea of why it takes so long to test.”