Do project managers need to think beyond their current project boundary? Do we need to have foresight? What do we lose if we don’t have it? When it comes to development projects, this author shares how we can look beyond success of the current project for something even more meaningful.
In a typical software development project, gathering and managing requirements is a common process. But what about IT infrastructure projects? Do they have specific requirements beyond the architecture diagram? Here are five lessons learned from an infrastructure project that struggled with missed requirements.
Collaboration inside the Department of Defense is critical to program success, especially for enterprise-wide applications. DoD program managers face challenges unique to the DoD, including culture, organization dynamics and an abundance of complex statutory and regulatory requirements. Methods explored in this paper can assist the program management office (PMO) in achieving needed collaboration, and putting these in place at inception increases effectiveness.
The best way to plan a project is to deconstruct it. One PM has been using a handy model to clearly outline the types of work that need to be done by both IT and the business in order to activate most SaaS packages. Key an eye on these six subtleties when deploying packaged vendor solutions.
Organizations that over-emphasize expediency can set themselves up for long-term losses. This article addresses strategies for taking a balanced approach--specifically, maintaining development capacity, maintaining code asset value and flexible tool selection.
Trends on the horizon point to a renewed focus on the alignment of IT operations and strategic business goals. In addition, competition in all markets will continue to place pressure on both optimization and innovation. Savvy professionals can stay ahead of the curve by keeping the following project management trend predictions in mind.
Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. How can we act more productively?
The waterfall methodology for projects is aptly named, because it is equally painful to try to go back to prior phases of a project once the effort has advanced to the next phase. This article will outline two reasons to avoid waterfall, and three ways to approach software projects that are more useful.
Some studies have indicated that the real benefits of offshore outsourcing can be diminished by issues in communication, skill sets and accountability. But if managed properly, offshore IT projects can reap substantial rewards.
If Kanban works well on specific software projects, can it be scaled to facilitate Lean throughout an organization? Here we look at how Kanban can be thought of as a general purpose change management approach for your organization.
Question: The software developers in my IT department are hardcore agileists. I maintain legacy systems and do operational work. Is there anything I need to know about the agile world that could affect my work with hardware?
Yes. Cloud computing is an agile practice and a major trend that will probably be discussed in your workplace soon. Learn about it so you don’t look dated and out of touch.
No. Agile is only for software developers at large shops like Google who need to support online retail sales and search engine banks.
Yes. All hardware purchase and installation projects should be converted to a Scrum process for the greatest impact and cohesion between teams.
No. The government has legislation pending to block agile practices as potential antitrust violations.
Call it application sprawl, application bloat or whatever you like, most companies that rely on applications could use a good old-fashioned spring cleaning to reassess and determine which apps in a company’s portfolio provide unequivocal value and which should make a polite exit.
In an attempt to help those of you struggling with Business Process Improvement and Business Process Analysis, our expert presents these “anatomical components” in terms of a series of rules so that you can use them in your efforts.
It doesn't matter whether you work for a big or small company: When delivering a product that requires the work of more than two teams, dependencies are part of the picture. Time after time, projects are tangled up in dependencies. Does it have to be this hard? Some dependencies are inevitable, but some are self-inflicted...
Cloud Computing just might hit its stride in 2013. But while the momentum toward Cloud Computing is consistent within larger organizations, the reasons for the push are not...and not everyone is jumping into the Public Cloud pool.
Standardization is the “copy and paste” method of process development. It’s as bad in spreading process through an organization as “copy and paste” is in code. Copying a working instance may be a good starting point, but it’s a bad destination. Creative work needs attentive thinking, even when deciding to not change the status quo.
If you are to grow as an agent of organizational change, then you have to keep learning. Sometimes the learning comes from understanding your successes, sometimes by reflecting on the failures of others. But perhaps the most long-lived learning comes from internalizing ways not to repeat personal failures. Here are one seasoned PM's top five lessons learned along his 37-year (and counting) journey through the world of project management…
Too often, the organizational focus is on relieving symptoms, not necessarily solving the problem. The culture of these organizations is that as long as the user problems can be fixed, then the issue is “solved”. Not only is that inaccurate, it’s inefficient and risky. Quick fixes are not permanent solutions, so when bandage solutions and workarounds become the norm, it’s time to act.
Large-scale change of enterprise-level architecture and infrastructure presents a challenge, especially in today's networked world. Enter agile project management. In our concluding installment, we look at successful architecture and design from history, explore the challenges that come with the principles of evolutionary architecture and design--and identify a short list of evolutionary design principles.
Application development and delivery has changed dramatically in recent years...have you? Many areas have been well documented, but in the midst of all that there is another change happening. Who's in control? That’s what we explore here.
Large-scale change of enterprise-level architecture and infrastructure presents a challenge, especially in today's networked world. Enter agile project management and the ideas of refactoring and continuous improvement, which involve creating innovative new solutions for each problem encountered.
Part 1 of this series discussed the background environment and philosophical divergences that caused agile to establish itself as an alternative to traditional project management. With that background established, it’s now time to start thinking about the where agile is headed and how it will get re-contextualized for the 21st century.
With the steady industry shift away from custom code applications to more commercial software packages and services, IT project management practices are necessarily changing to adapt to the new conditions. Is this a glimpse into what the future holds?
"If you think you've hit a false note, sing loud. When in doubt, sing loud."