This template was created with consideration to the billion-dollar fantasy sports media industry--and specifically the mobile application market. Every project manager in this industry will have different approaches to managing business communication, thus deeming it necessary for you to adjust this template in order to reflect needs specific to your organization.
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.
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?
No longer a possible notion, idea or discussion point, the whole cloud concept has been getting considerable traction in mainstream IT operations. But what is up and coming for this technological evolutionary jump, and what will be needed to support it?
It’s a universal problem for IT project managers everywhere. When you’re managing a system implementation you are responsible for the total solution--that means application and infrastructure. The problem is that these two camps haven’t always gotten along. Here, we look at how to make bridging the gap between infrastructure and applications in your project technology stack as easy as, well...a piece of cake.
Having a great product and seeing how its application potential could be exercised across a business, industry or many industries is exciting--but also daunting. The control you have over your product components cuts down on outsider adjustments. Keeping that control, though, may require making yourself available to the opportunities of customization and specialization.