Balancing Critical Project Success Factors – Selling Good Ideas

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” In the Introduction article we outlined the five prescriptions for preserving the balance between project success factors. In this article, we look at the first prescription – sell good ideas by emphasizing benefits that the user perceives as valuable.

Selling Good Ideas

The starting point for an IT project is selling senior management within the user group and within the IT function on the idea. Consequently, the efficiency with which ideas are sold is one important means of managing priority pressure. The power of persuasion depends largely on whether the rationale used to support an idea resonates with the decision-maker’s interests. To sell ideas more efficiently, the rationale for an idea must reflect the user’s priorities. In short, reasoning should always outline “what is in it for them.”

When selling ideas, IT professionals sometimes get stuck on technical issues, specifications, and justifications. Although technical details are critical, as facts, they have limited power to influence users and senior IT management. As a result, one of the main priority management prescriptions is that IT professionals need to develop sufficient business expertise to engage users in terms that they will find compelling. IT professionals who add this expertise to their technical competence have the greatest organizational impact. Many IT organizations are experimenting with the role of user or client relationship manager to help establish client sensitivity within IT organization.

Selling ideas effectively also means having good ideas. Good ideas are designed with knowledge of the practical time and resource constraints within which they will be implemented. Not all business problems require state-of-the-art solutions.  Sometimes, small is beautiful. Making incremental enhancements over time can moderate the negative influence of organizational politics, limit risk, and create success experiences. A track record of successful enhancements can build momentum for bigger, more ambitious projects.

Having a good idea is not sufficient, however. Good ideas are often not met with enthusiasm. How the IT professional responds to the objections raised by others as the idea is being sold affects one’s eventual success. Arthur Schopenhauer, the nineteenth-century philosopher said that ideas go “through three distinct phases: ridicule, opposition, and finally enthusiastic acceptance.” Advancing ideas through these phases means (1) increasing perceived need for the idea, (2) modifying the idea itself to increase personal and organizational benefits to key stakeholders, (3) reducing costs, both personal and organizational, and (4) decreasing perceived risks. By adjusting good ideas iteratively based on feedback from stakeholders, IT professionals can efficiently win a critical mass of support for IT projects from key stakeholders.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Safran’s new Product and a PM Job

Project Manager – Digital/Online Projects
Our client, voted Digital Design Agency of the Year for 2007 and 2008, an ideas driven, design focused and strategically minded design agency is looking for talented Project Managers with Account Management experience for their growing Johannesburg office.

They specialize in the creation of digital campaign solutions for all sectors of business making their clients stand out from the crowd. Services include strategy, design and the technical development of solutions across all digital media space.

Do you like a challenge – being hands on? You will be involved in all matters from client briefing, budgets, traffic and project management?

• Experience working on digital projects is an absolute must!
• Knowledge of digital design as well as knowledge of digital front and back end is essential.
• Experience of working in a creative agency environment (beneficial)

Requirements:
• At least three years Digital Project Management experience
• At least three years of client facing experience
• Understanding of digital design and creative website development and functionality
• Knowledge of digital front and back end
• Running complete online to mobile to integrated campaigns
• Must have technical knowledge (how a website can work & different platforms it can be used on)
• Basic understanding of online and offline.
• Experience producing, trafficking and seeing through the development integrated digital campaigns that involve:
- SMS campaigns.
- Websites, Mailers, online banners (flash, gif and rich-media – must have been exposed to this from a non-technical side.)
- Processes of working with social networks like Facebook, Twitter and mobile marketing.
- Knowledge of programming languages and what is best used in various situations.
- Knowing the difference between an intranet and a portal (for example)

Apply here..

Safran North America Releases Proteus Product into North American Market
Market-tested Project Integration and Intelligence Product introduced to new market

Albuquerque, NM (PRWEB) July 2, 2009 — Safran North America (SNA), one of the world’s leading manufacturers and distributors of project management applications, announced today that it has added Proteus to its product offerings to serve the North American market.

Over seven years in development and proofing in the most demanding project management environments in transnational corporations, Proteus is an integration and intelligence application that connects to project and/or enterprise information regardless of location, database system or underlying application. It is based on .NET it can access geographically dispersed data sources over the web as well as secure networks. In summary, Proteus is a virtual multi-application smart client operating across an organization with security attributes for each user or group of users in addition to any security acquired from the database.

“We are extremely excited about the capabilities that Proteus offers to our market ,” said Safran North America CEO, Nicholas Pisano. “We expect that Proteus will be a game-changer, particularly since it leverages the next generation of tools, by-passing the dead-end reliance on OLAP or Cubes to achieve data integration. Turning data from disparate systems into corporate information aggregated as appropriate based on a user’s role in the organization.”

read the full article here..

Agile Software Development in a Standard Project Management Methodology

I’m sorry everyone, but I’m going to do it again. I’ve learned a lot from the Agile vs. Standard software development process discussion that is still going on based on two other articles (“Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”).

In very early articles I discussed the general hybrid project management process I use to manage projects. In practice, it incorporates these phases:

• Phase 1 – Project Kickoff
• Phase 2 – Exploration
• Phase 3 – Design
• Phase 4 – Development
• Phase 5 – Testing
• Phase 6 – Training
• Phase 7 – Deployment
• Phase 8 – Post-Deployment

Process Flexibility

I realize that all project management needs to be flexible to some degree. We need standard practices and templates in place to follow or we are destined to failure. We need some flexibility because not all projects and customers and resources are the same. But not too much flexibility because structure and order lends to repeatable processes and practices and usually leads to greater success and a better understanding of how that success came about.

So the agile question this time around is this…can an agile development process be fit into a standard project management methodology? Or does the entire project management methodology and process for the project thus become agile as well?

Project Management in an Agile Environment

Design, Development and Testing phases would be modified to accommodate the rapid and iterative development, testing, and rollout process that is dictated by agile development methods. That’s understood. But are the project management processes used on standard or waterfall development projects usable for an agile development process or does the entire project management process need to conform to the agile development process?

I’m pretty sure I’m educated enough on this to understand how this needs to go, but I welcome the on-going discussions here because it is certainly further educating me, and I know it is also educating and interesting others who may or may not be aware of agile development and project management processes.

One of my colleagues/readers on here noted that good project management must always be agile because requirements are never firm…they are always changing to some degree. Even I realize that even though I tried to present the ‘perfect’ requirements scenario in the two articles mentioned above.

He also stated that “outcomes” need to be emphasized over “output”. A very good point and observation. A standard project management process does a nice job of emphasizing output – each phase has outputs and deliverables that need to be reviewed and approved in order to move on to the next phase. Whereas an agile process emphasizes the outcomes – successful packets of work that build on each other.

I look forward to the discussion to follow – it will make me a more flexible and educated project manager…and I’m always interested in learning.

Senior Project Manager – Rail

Location: London
Salary: £45000 – £50000 per annum + Ful Package
Company: Capita Technical Services
Sector: Commercial
Job role: Project manager
Job type: Permanent

Job Description:

My client is a and is a top 5 consultancy business, specialising in property and infrastructure services to both the public and private sector. Operating all over the UK, with services including project and cost management, transport planning, environmental consultancy, design, engineering and construction management.

The Rail Team is a key part of the Infrastructure Division of and comprises of Commercial Management, Project Management and Controls and Engineering.

My cliern has an exciting opportunity for a Senior Project Manager to join the fast growing rail team where career defining opportunities are offered. Successful applicants will thrive on being part of a team orientated environment contributing fully on both rail and other infrastructure related projects.

Successful candidates will lead the safe delivery of all aspects of the full project cycle. Ensuring that quality and value for money are met, and keep specifications and agreed targets for cost and time scale and manage a team of less experienced staff.

The post holder will provide professional, first class, consistent and effective project management service to the clients, aswel as participating in the development of supply strategies and frame work contracts.

Apply here..

Agile vs. Waterfall – More Thoughts

Ok…I have to do a follow-up to my article “Agile Software Development Project vs. Standard Software Development Project.”  It was only posted a week ago and has already generated 20 comments.  And many have been from Agile supporters who can’t even comprehend a scenario where a ‘standard’ or waterfall approach results in a successful project.

You would think I had just stated that Pete Maravich wasn’t the best ball handler in basketball (which he was) and that Cheap Trick wasn’t the greatest rock band in the world (which they are – and you can buy their new CD “The Latest” from Amazon here …sorry for the plug, I know those guys, I know their families and they are hard-working and still at it – so buy the CD already!).  Ok…where was I?

Oh yes, I was lightheartedly discussing reaction to my Agile vs. Waterfall article from 6/11/09.  I’ve been reading all comments and have responded to many of them.  However, based on the comments that have been coming through, I think I need to actually follow-up that article with this one to further clarify my thoughts, the question, and what I’ve learned so far.

My Agile/Iterative Process Background

Let’s start with the understanding that I’ve never worked in an organization that subscribed to Agile practices of software development or project management.  I was leading an enterprise software re-write project that was utilizing an iterative development process for a large customer in Las Vegas when the company I was working for abruptly shut down.  We were through requirements and ready for development so I was already seeing the benefits, but we weren’t able to complete the process.

My Standard/Waterfall Background

Let’s also acknowledge that I have worked very successfully as a Project Manager for 18 years now – all basically using the waterfall method for software development projects.  Yes, I’ve seen some failures – both in projects I’ve led and in projects colleagues have led.  Some have ended in a fiery death for the project and careers.  But many have been wildly successful – I wouldn’t be here today if that weren’t true.  I’ve led many small and many very large projects using standard waterfall methods that have ended with happy customers, on time deployment and on budget financial status (except, of course, for necessary change orders as a result of customer and project needs).

Being what I consider an intelligent individual as well as an experienced developer, project manager and IT professional, I can make the educated statement that any process that requires continual customer involvement, short sprints that test and rollout a solution every 2-4 weeks, and constant attention to evolving requirements is bound to have frequent success.  The main problem with any waterfall approach is the fact that the project is based on an understanding the requirements are in place correctly at the beginning.  That’s flawed – they are almost never correct or in enough detail when the project kick’s off.  They usually evolve over the course of the project – with more detail and more surprises extracted along the way…unfortunately.  Usually this requires re-work.  Often it requires change orders.  And sometimes it upsets the customer.  All of that is known by everyone and completely understood by this author.

The Scenario…Again

Finally, I’d like to restate my premise for all.  If a software project has well-defined requirements up front with no need for further definition (yes, rarely, if ever happens…I know), and if the customer is continually involved and everything goes smoothly and your project is well staff with the right skill set…then if you used each method to run the project I am assuming that the overall project costs for the waterfall method would be less than with agile.  This would primarily be  because of less testing, overhead, etc. 

I’m only asking for one hypothetical project, not the best way to run a project and not the best method across a portfolio of projects.  Just one perfect project.  Would it be cheaper to do waterfall than agile assuming no re-work, no re-starts, and no issues?  My guess is “yes.”  And that’s what I’m basically hearing in the comments.  Your thoughts?