Project Management

Project Management 2.0

New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog


Recent Posts

Are You Prepping For The PMP 24/7?

Are You Just Too Darn Busy?

Eliciting Requirements... Creatively!

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

What's Your Requirements Architecture Mean to You?

Situation: You want to understand how organizational influences impact your work.

A project starts as an idea.  That idea turns into something more concrete, then goes through cycles of changes – influenced by people, tools, timing, and more.  As new tools are brought in, organizations look at their projects through different lenses and those points of view affect project results.  I think it’s interesting to look at where your organization is focusing on and how its influencing projects.  Understanding your organizational bent can make you more effective within your own sphere of influence.

Is getting what you intended to do - “Done” - most important?
A single software project involving several developers can involve requirements that are complex enough for any project manager.  Of course, there are Software Configuration Management (SCM) tools (What we used to call Version Control Systems) that help development teams manage versions of software and the related changes that are made during the development process.  Project Managers are typically concerned with changes at a higher level – looking at release cycles and business requirements that are more visible to sponsors.  For many companies, this is where requirement tracking stops and they’re happy with it that way.  Jama Software recently came out with a JIRA (defect tracking) connector for their Coutour (requirements management) product that they feel addresses the most critical communications gap that exists in requirements management, bridging developer-speak and PM-speak.  The focus here is on specifying exactly what is needed and verifying that its getting done. (AKA “doing things right”)

Is reviewing what’s being done and refocusing most important?
Add more projects, some spanning various functional areas of the business, and you can create a real management nightmare – even if what you are building is well defined in every case.   Portfolios of projects nearly always create the need for an even higher level of shared understanding between PMs and executive management.  Strategic prioritization efforts influence project requirements in unexpected ways almost as a PPM side effect.  If, as a project manager, you’ve ever been blindsided by a large scale change in plans – you know the impacts here can be huge.  In theory, at a high level the right things are always being done.  (AKA “doing the right things”)

Is optimizing the use of resources most important?
For larger organizations,
we’ve talked about Application Portfolio Management (APM) that aims to reduce the size and maintenance costs of the application portfolio so funds can be put towards new strategic development.  For companies that need a more robust way of tracking incredible complexity and optimizing the use of resources to create strategically important outcomes is most important.   (AKA “doing the right things in the most effective way”)

What does your organization focus on?  Is it driven by new tools being brought in?  Why does it work or not work for you?

Posted on: August 01, 2009 10:51 PM | Permalink | Comments (4)

What Matters When Defining Requirements?

Categories: Requirements

Situation: You want to give your approach to requirements a little more thought.

Is requirements definition your biggest challenge when defining success on your project?  Or is that that one concern among many?

JAMA software and Raven flow are conducting a survey related to requirements gathering that you may be interested in.  At the very least, its a quick way to give some thought to what matters to you relative to requirements gathering.

Here are some early results from John Simpson of JAMA ...
Respondents are:  37% are Analysts, 24% Project Managers, 12% Product Development/Engineering, 6% Product Managers, 5% Exec Mngt
54% of respondents work for companies with $100 million annual revenue or more (25% are $1 billion +) so a good range of large and small companies
The biggest requirements challenges were:
70% gaining a clear understanding of what our customers want
64% ensuring what’s being built is what was planned
63% documenting all the requirements
The goals of their projects:
75% are for enhancing existing products
59% bringing new products to market
25% reducing costs of producing existing products
29% of them considered their companies “Risk Takers” when it comes to innovation, the largest camp was “Market Readers” at 36%, 16% were the “Low Cost Provider”
73% rely on customers and partners for new product ideas – so external collaboration is critical
In terms of complexity, 39% of respondents on average had 500+ requirements for typical project, 22% have 1,000 or more requirements
In terms of the burden of change management,  over a third of respondents spend 25% or more of their time dealing with changes to requirements
How they measure success:
87% customer satisfaction
52% quality/safety ratings
34% cost savings
32% revenue
25% speed to market (interesting in terms of positioning)
And the one they personally cared the most about was “customer satisfaction” at 61% – I thought it was interesting that “revenue” wasn’t higher (it was only 6%)
In terms of delivering projects on time and on budget:
For over half of respondents, the project success rate is 40% or less; so they’re feeling the requirements pain
The top reasons were:
74% scope creep
64% missed or poorly defined requirements
61% unrealistic schedules or expectations
51% team communication/collaboration an issue
44% Misunderstanding of what customers want
39% Issues w/ change management
29% Lack of executive support
What they personally find most frustrating:
Missed or poorly defined requirements was #1, unrealistic schedules #2, misunderstanding of the customer #3
The majority define “collaboration” as these 3 things:  everyone is in sync on the latest version of the requirements(80%), all items in centralized place (72%), everyone has access (66%)
No surprise, 80% currently use Word or Excel to define and communicate requirements; 31% currently use requirements definition software, 35% use a requirement management software, 40% using email
On the list of tools they’d like to use in 2008 – 59% chose requirements modeling & visualization, 62% requirements collaboration & management
In terms of processes:
37% are using a mix (so having tools built to handle various processes is probably a good thing)
26% traditional Waterfall
16% using RUP or some variation of it
And despite all the attention around Agile these days, only 5% answered using some flavor of Agile process currently – was a bit surprise Agile wasn’t higher
Posted on: April 16, 2008 10:34 PM | Permalink | Comments (6)

Managing An Entire PORTFOLIO of Requirements

Situation: You Have a Need (perhaps an ITSM push?) for Highly Integrated Change Management.

MKS Integrity helps you manage software development at every level of the process, even giving you a portfolio view of what's going on based what's really happening on the ground at the task level on all portfolio projects. IT Service Management is still very hot across the industry right now and software like the MKS toolset plays a huge role in supporting those efforts. Recently, Doug Akers, Tactical Product Manager for MKS spent some time with us answering some questions about the tool and what makes it unique. As will most tools, it is broadly applicable across IT and gets a lot of traction in engineering organizations who are delivering many similar products - industries like Telecommunications, automotive, medical devices, and embedded systems.

Q. What differentiates MKS from other requirements management software vendors? Less in terms of technical features, but what do customers say they like better about it?

Customers, in my experience, tend to like the connected nature of the MKS Integrity solution and the fact that everything is right there at their fingertips. There is a huge difference between integrations and a truly integrated solution and I think the demands of visibility, transparency and communication that fall out of our solution are proving to be differentiators for our customers and their ability to deliver projects on time. An integrated offering is still many tools, and users have to weed through the complexity of those tools while with MKS Integrity, it’s all one platform, one interface, one way of working. Test management, source control and requirements management all use the same platform capabilities and all benefit from the versioning, reuse, change management and process control that is part of that platform.

Q. Tell us about the “unified approach” to requirements management.

Traditionally, the tools across the application lifecycle have been very siloed, very purpose built – you have your RM tools, your versioning tools, your testing tools – and although these tools work for their discipline they also put up barriers to collaboration, optimization and the ability of the organization to be productive. There is tremendous benefit to the developer when they can easily click up the tree to see the requirements driving their tasks – it gives them context for their work and allows them to deliver more optimal solutions that meet the business needs. You can’t get that in a siloed world and you can’t get that easily with traceability alone, which is a commodity feature in today’s RM market. A unified ALM platform that addresses RM, as MKS Integrity does, enhances traceability with concepts like transparency and visibility at all levels of the organization.

The unified approach gives you a lot of free stuff too that maybe weren’t high on your list. Single administration, single security, integrated process across groups…………

Q. “Reuse” is a hot topic lately. How are project documents and code reused using MKS Integrity for RM? How is that different from competitive tools?

Reuse is a widely abused term, what does it really mean in practice? I mean, open Microsoft Word and copy/paste a paragraph from one document into another, is that reuse? Some competitive tools would try to tell you it is. MKS, as a company, has a very strong foundation in the software configuration management arena – MKS Integrity has been doing version control and configuration management for more than 20 years. All we did to address the needs of our customers was apply those concepts to the RM space – we’re treating a requirement the way we treat source code though with a business user interface. Requirements are truly versioned, branched and shared across projects, across documents, across the organization and their genealogy is preserved and leveraged. It’s real reuse, not just copy and paste.

Q. How do users connect requirements and other life-cycle artifacts such as test cases, defects, release definitions, UML or design models, etc.? How does that compare to establishing relationships between requirements?

MKS Integrity, to over simplify things, tracks items and has relationships between these items. It doesn’t matter whether these items are test cases, defects, requirements or source code objects they all benefit and leverage the same set of platform capabilities. Traceability is a fancy term for connecting artifacts across the application lifecycle. In the MKS solution, making those connections between requirements or to artifacts in other disciplines is a simple drag and drop gesture if the system doesn’t already take care of it for you, which in many cases it does.

Q. What words of advice would you give to someone struggling with requirements management issues?

Don’t eat the elephant all at once… but know that you have an elephant to eat. There are several RM issues that I find within the organizations I talk to – anything from not being able to effectively capture requirements, not being able to know when things change, to not being able to leverage the investments they do make in good requirements – and underlying all of them is process.

Process is not a tool dependent thing, it’s a business dependent problem and you will want a tool that can enforce your process rather than a process that conforms to the limitations of a tool.
Posted on: February 09, 2008 09:18 AM | Permalink | Comments (2)

"Put all your eggs in the one basket and - WATCH THAT BASKET."

- Mark Twain