Working on IT Projects of the Future
Posted by Elizabeth
According to Gartner, IT departments in 2012 will look fundamentally different to the IT departments we work in now.
The analyst company has predicted that an IT department will add four new roles to the team in the coming years. None of them are specifically project related but they all have an impact on the way in which we manage IT projects.
The roles are:
- Litigation support manager
- Enterprise information architect
- Digital archivist
- Business information manager.
Build a Web Worker Friendly Project Management Office
Posted by Arjun ThomasSourced from Web Worker Daily.
Management Offices (PMOs) to centralize project management activities. Just as organizations have to change some of their processes to accommodate web working, PMOs have to be at on the forefront of those changes to manage organizational projects to successful delivery.
Here are some tips if you are seeking to build a web worker friendly PMO to manage geographically dispersed employees, contractors and partners:
Democratize Project Management Data. The democratization of project data has been an ongoing theme in some of my recent project management posts; it becomes more important as project teams leave the confines of the cubicle farm. PMOs need to become more polished communicators of project status data (including schedules, risks, and client requirements) and target audiences at every level of the project from the “worker bee” all the way up to the executive stakeholder. The challenge is that the information has to be understandable by everyone — meaning that views of project data cannot always be shared just by using a Gantt chart.
The Need for Formal Project Change Control
Posted by Brad Egeland
A rigorous, formal change approval process will enable you to maintain control of your resources and integrate approved changes into the product or project development flow. Many large development organizations already have a formal change proposal review and approval process in place and if that is the case in your organization, count yourself blessed. If it is not, then it may be worth your while to read on and understand why it is so important.
A change approval process maintains your resource control
Post requirements baseline changes are trouble – the purpose of the baseline was to drive a stake in the ground that signaled the beginning of development and a large increase in the rate of spending. Before you “just say no” to a proposed change, however, you must understand the change and its impact. Some proposed changes are necessary for the product to succeed, whereas others are only nice to have. Among the necessary changes are those that “fix” a bad requirement; those that add forgotten, but needed requirements; and those that alter existing good requirements to meet a new customer or market goal or objective. Almost all change proposals, if approved, will require some development rework, overloading your critical, limited resources. Your team cannot build a product or solution to a moving target. You must limit the changes to those that are absolutely necessary.
A rigorous change proposal review process gives proposed changes visibility before implementation. It ensures that you will know about all change proposals, their justification, and their cost. It also enables you to veto the proposals that are unnecessary or impossible within existing resource allocation. It protects individuals on the development team from external change pressure.
A formal change approval process helps integrate changes into the development flow
Once a change is approved, you must quickly and fully integrate it into the project or product development flow. You must do this change implementation without knocking the entire development effort off track. A rigorous change proposal review process gives you and your team the data required for thorough project re-planning and change implementation. This data includes a complete assessment of the change impact and its cost.
Summary
The key is to first understand the importance of your requirements to the overall engagement and the need to baseline those requirements and protect them carefully. No change should go through without close scrutiny and the customer must be onboard from the point of project kickoff with the need to control the project scope in order to help ensure project success. Preach the problems that can and will arise from continually changing requirements because the need for good up front requirements can never be under-emphasized.
Lafayette Building falls in slow motion
Posted by Arjun ThomasSourced from Freep.com
The long, slow death of downtown’s Lafayette Building has given gawkers something new to look at and bloggers something new to complain about online.
Detroit’s Downtown Development Authority voted last June 25 to demolish the vacant office building. Seven months later, the building was still only half down this week, with a lot more work to go.
Waymon Guillebeaux, vice president of project management for the Detroit Economic Growth Corp., which oversees the demolition, said two major delays cropped up since the DDA’s vote.
First, nearby filming of the movie “Red Dawn” stopped demolition work, and then a sinkhole on nearby Shelby necessitated a water main replacement that also stopped demolition work.
Should Technology Drive the Solution?
Posted by Brad Egeland
“Oh…pick me, pick me Mr. Kawtter!” (as Horshack would say to Kotter for those of you old enough to remember – see image to the left) I know this one. But wait, new technology is so cool…and so much fun. And often the customer comes to you with the solution in mind that includes this technology. And sometimes he even has the money to back it up. Resist! Resist at all costs!
The answer is a resounding NO. Technology should not drive the solution. Never ever ever. It may be the solution, but there’s work to be done first to get there. Follow the process, push back on the persistent customer who knows exactly what he wants and how he wants it done. Take a deep breath and tell the customer simply …. no.
Why? You would think that a customer who has money, has a need, and knows the solution is an easy customer. All we have to do is do as he says, cash the check, and move on to the next project – everybody’s happy, right? Not always … and not likely.
The problem with this scenario is that the customer often doesn’t really know what they want. What they know is that they have a need. The customer needs help cultivating the information from that need into a solution that will fit or solve that need. That’s where you – and your team – come in. Being a ‘yes’ man for the customer won’t do them any favors and will more often than not leaving them with a final solution that doesn’t meet their needs. If the customer’s end users are frustrated, the customer will be frustrated. And customer frustration = customer dissatisfaction.