Monday

Tag Archives: Agile

Workflow Management

Posted on May 31, 2014 by | 1 comment

Many projects involve repetitive elements of work that take some inputs, run them through a series of processes and deliver an integrated output.  Standardising these elements of project work can create efficiencies and minimise errors.   A couple of examples include normal ‘sprints’ in an Agile project and the monthly updating of the plans and reporting in a major project. Workflow management sit one step above individual processes (particularly standard operating procedures) linking them into an optimum sequence of work.

Workflow management means to oversee the creation of a deliverable from beginning to end. The management aspect is to be able to identify the people who need to be involved in each process within the work flow and to ensure the ‘flow’ allows for input from all required parties in the right sequence. The key questions that need answering to create a productive workflow are:

  • What is the optimum sequence of processes?
  • Who needs to be involved in each process? This includes knowing what inputs are required to start the work and what outputs are produces to finish the work.
  • How to keep the momentum going within each process and the overall workflow (and the timely identification of blockages)?

A workflow can be simply designed on a piece of paper (or white board) to show the flow, who is responsible for each process and how the tasks are accomplished; or automated.

 

An example of an automated workflow management tool from http://www.comindware.com/tracker/

The key advantage of developing and using a workflow is you can expect similar results from the accomplishment of the work at each iteration, even if the people involved change. It reduces errors and provides consistent results.

Agile projects use the concept of ‘done’ at the end of a sprint. A common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects. Teams define the series of steps needed to reach ‘done’, and implement them routinely through each sprint. The steps to get to ‘done’ may include:

  • Code Complete
  • Unit tests written and executed
  • Integration tested
  • Performance tested
  • Documented (just enough)

Build these steps into a workflow and everyone benefits – particularly if the workflow is reviewed and updated to incorporate learned experience on a regular basis. The art is to keep the workflow as simple as possible but not so simple that it becomes simplistic.

So next time you wade through the tasks needed to create your monthly report or any other repetitive job within the overall management of a project think about documenting the work flow – it will pay dividends over time.

1 Comment

Posted in Agile Ideas, General Project Management

Tagged , , , , ,

PGCS 2014 Update – I’ve been proved wrong!!

Posted on May 7, 2014 by | 1 comment

The Project Governance and Controls Symposium 2014, Canberra, is in full swing with wall-to-wall interesting presentations!

The focus of this post is the presentation by Stephan Vandevoorde on the work he is involved in at Ghent University, Belgium focused on developing  processes for the validated testing of project control tools entitled ‘If Time is Money, then Accuracy is Important’.

The problems with studying the effect of project control processes in live projects are many, the most significant being:

  • The control function generates information that influences management action causing different outcomes.
  • The ‘Hawthorne Effect’ where people being ‘observed’ change behaviour because they are being observed.
  • The uniqueness of each project, its team dynamics, luck, and the overall operating environment making replication of an ‘experiment’ difficult.

As part of their on-going work to validate Earned Schedule (ES) the Ghent team have developed a set of project networks using different topologies to emulate schedules ranging from those that are largely sequential, through to those that have a high level of parallel working.  The models are updated with a range of 9 different progress options leading to a total of 2.8 million unique data sets. This resource provides a unique test bed for evaluating the effectiveness of various predictive and preventative tools and techniques.  For more on this valuable resource, which is available for research, see http://www.or-as.be/research/database

One of the earlier studies (on a smaller simulation) focused on testing the effectiveness of various techniques in predicting the final schedule outcome of a project. And this research has proved me wrong!  In a blog post following last year’s PGCS ‘Earned Schedule comes of Age’  I lamented the fact that a detailed study proving Earned Schedule (ES) was significantly better at predicting project completion than the traditional Earned Value SPI had not taken the extra step and also demonstrated its predictive effectiveness compared to traditional CPM.  My paper Why Critical Path Scheduling (CPM) is Wildly Optimistic highlights the issues but lacks statistical validation.  As it happens, the ‘missing’ studies had been done and the outcomes presented by Stephan showed the results of a 2008 study by Prof. M. Vanhoucke (also of Ghent University) that demonstrate the superiority of Earned Schedule as a predictive tool designed to complement the true focus of CPM which should be the optimisation of resources and workflow (rather than the projection of the overall project completion – for more on this read my paper).

So the basic research has been done, the results are conclusive and based on the research the effective controlling of projects needs a combination of CPM, EV and ES for optimum results!  The research frontier is moving towards effective early indicators such as the ‘P factor’ and intervention and with the data tools now available, statistically  significant analysis becomes feasible.

With the steady stream of papers validating Earned Schedule, I hope the flow of misleading information from a few die-hard traditionalists in the USA is finally extinguished and comments from leading authors such as Quentin Fleming and Joel Koppelman in the  4th Edition of ‘Earned Value Project Management’ (2010), that ‘The authors do not endorse [earned schedule]. Nor have they ever read any scientific studies that support [it]’ disappear.  It really does not matter what Fleming and/or Koppelman have bothered to read, making misleading statement like this helps no one.

The challenge is developing tools and techniques that help manage projects in an environment of increasing complexity – and as one of the other presenters, Stephen Hayes from the International Centre for Complex Project Management (ICCPM), traditional tools such as CPM and EV are important, but simply not sufficient in the emerging domain of complex project management, or  as my paper to the PGCS suggests, Agile projects.

1 Comment

Posted in EVM & ES

Tagged , , , , , ,

Project Governance

Posted on December 11, 2011 by | Leave a comment

Corporate governance is defined as aligning as nearly as possible the interests of individuals, the organisation and society. Good governance is good business!

Project governance is a sub-set of corporate governance, focused on systems that ensure the right projects and programs are selected by the organisation, and the selected ‘few’ are accomplished as efficiently as possible. Projects that no longer contribute value to an organisation should be terminated in a way that conserves the maximum value and the resources reallocated through the portfolio management process to more valuable endeavours.

The framework for effective project governance is laid out above, and is an executive management responsibility. Sponsors and the Portfolio Selection/Management processes provide the key link between the executive and the working project and programs (for more see our Governance White Paper).

The focus of this post is to look at the pre-selection activities that inform the portfolio selection processes. One of the key conclusions to be drawn from the Ombudsman’s Report discussed in my earlier post Cobb’s Paradox is alive and well  was that many of the projects that contributed to the $1 billion in failures were set up to fail – the projects had absolutely no chance of delivering within the announced parameters: the inputs to the portfolio selection process were grossly flawed (or were non-existent).

This appears to be a wide spread issue. Most project management standards such as ISO21500 and the PMBOK® Guide start with an approved project and a business case or similar that defines what has to be accomplished; this is the end of the portfolio selection process outlined above and is assumed to set realistic and achievable objectives.

What is missing, are the steps leading up to this point; the life of a ‘project’ starts with an idea, need, opportunity, requirement or threat (the ‘concept’). The organisation assesses and studies the ‘concept’ hypothesises options and solutions and frames a proposal that becomes the foundation of a future project. These key investigative elements of a project generally sit under the portfolio umbrella developing information to allow a proper decision to be made. In mining this can represent exploration, feasibility studies, ‘bankability’ studies and concept designs which between them can cost $millions, leading to project funding. Importantly, this ‘Front End Loading’ (FEL) is seen as the key to a successful mine in most major mining corporations.

Similar problems exist in major infrastructure projects, defining a solution to prison overcrowding can involve building a new major prison, building several smaller prisons, extending current prisons, changing the way criminal justice system works to reduce the need for prison places, or a combination of the foregoing options (substitute University/hospital/school, into the previous sentence to see just one dimension of the challenge). However, unlike mining, most government and many corporate organisations see effective ‘front end loading’ as unnecessary.

Other organisations use the process to formulate definitive solutions to problems they have no real understanding of (typical in ICT) and then pretend the defined solution has no associated risk (because it is defined) despite the fact the full dimensions of the problem the project is supposed to solve are still unknown, and are frequently changing over time.

The challenge, requiring informed judgement and effective governance is recognising which development processes suits what type of ‘concept’:

  • Sometimes, the ‘investigation’ requires a significant amount of work (eg, a bankability or feasibility study); this work may be treated as a project in its own right, and is time, cost and resource constrained with a defined deliverable (the report).
  • If the work is expected to flow forward and will only be stopped in exceptional circumstances, project phases work best, with some form of ‘gateway’ or transition review.
  • In other circumstances, studies are undertaken as part of the portfolio by corporate or PMO professionals with no dedicated budgets, assessing multiple proposals as an ongoing process, but once a concept gets the go ahead a project is created and a budget and resources allocated.
  • Other concepts (particularly problems) cannot be defined and an ‘agile’ approach is needed where elements of a partial solution are developed and put into use developing new learning that will then allow the next module to be developed in a progressive sequence. However, whilst this may be the most suitable and cost effective way of developing an effective solution, budgeting in a traditional ‘iron triangle’ concept of fixed cost, time and scope is impossible.

The challenge is recognising which type of project is being proposed (based on Project Typology), and then deciding which type of process will develop the best input to the portfolio selection process and what level of uncertainty (risk) is associated with the proposal once developed. Certainty is not important, what matters is appreciating the extent of the risks and the likely benefits, so an informed investment decision can be made. Most ‘game changing’ initiatives involve high risk, high reward projects that create a totally new future!

OGC Gateway™

The OGC ‘Gateway Reviews’ is a flexible process that addresses this part of major projects from the client’s perspective:
Gateway 1 = Business Justification, options identified and appraised, affordability, achievability and value for money established.
Gateway 2 = Procurement strategy, will the proposed strategy achieve the project objectives?
Gateway 3 = Investment decision, based on realistic project cost information (eg, tenders or bids) can the business case be confirmed from both the cost and the benefit perspective?
Gateway 4 = Readiness for service. The completion of the project work and a reassessment/confirmation of the expected benefits as the deliverable is put into ‘service’.
Gateway 5 = Benefits evaluation. Did we get what was expected now the project’s outputs are being used?

Summary

Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed; if these decisions are wrong (or non-existent) project and program management cannot resolve the problem.

The role of effective project management is to deliver a realistic and achievable outcome efficiently; if the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation deteriorating further! As far as I know, none of the various BoKs and methodologies, including the PMBOK® Guide has a ‘miracle’ process that will magically transform an impossible set of objectives into achievable set of objectives. Wishful thinking is not an effective substitute for effective project governance!

Leave a comment

Posted in Governance

Tagged , , , , , , , , , , , , , , , , , , , ,

What is Agile?

Posted on February 9, 2011 by | Leave a comment

Agile? Sourced from http.yogadogz.com

Agile is not a project management methodology but Agile principles can and should be applied to the management of projects and in the right circumstances the various forms of Agile offer an effective way to develop software. In their original design, Waterfall and the various forms of Agile are software development methodologies, not project management methodologies, and effective project management adapts to the processes being used to develop the project’s deliverables.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavours; this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work, for more on this see: De-Projectising IT Maintenance

With these misconceptions cleared, there seem to be two key areas for discussion.

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

  • There is the need top select the right projects for Agile, for more on this see: Selecting the right projects for Agile
  • There is a need for a much lighter “touch” managing an Agile project; for more on this see: Managing Agile Projects
  • There is a need for a higher level of trust in managing Agile teams, for more on this see: Advising Upwards
  • There is a need for robust change management and configuration management to track the evolution of the Agile project
  • There is a critical need to develop the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

  • The need to trust knowledge workers more than manual workers
  • Success measured by customer satisfaction rather than quantitative outputs
  • The need to keep the client involved

Our discussion paper Thoughts on Agile looks at theses questions in more detail. The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated. The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Leave a comment

Posted in Agile Ideas

Tagged , , , , , , , , , , , ,

The Project Delivery Strategy

Posted on February 6, 2011 by | 8 comments

One element missing in much of the discussion around project management is a focus on optimising the project delivery strategy.

At the project level, strategic decision-making focuses on the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won’t change the required project deliverables but will have a major influence on how the project is delivered and its likely success.

One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholder’s expectations.

Some of the key steps in designing a strategy for success include:

  • Familiarization with the overall requirements of the project and its stakeholders
  • Determining the key elements of value and success for the project
  • Outlining the delivery methodology and getting approval from key stakeholders
  • Developing the project’s strategic plan based on the available know-how, resources and risk appetite of the stakeholders (including the project management team)

The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome within the acceptable risk tolerance of the individuals.

Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don’t know they need to be engaged at this critical stage of the project lifecycle.

Maybe its time for a change…… chose the wrong strategy and the project is destined for failure!

8 Comments

Posted in Stakeholder Management

Tagged , , , , , , , , , , , , ,

Selecting the right projects for Agile

Posted on June 13, 2010 by | 8 comments

I have just read an interesting article by Bob McGannon on selecting the right IT projects for Agile development. Bob is a Founder and Principal of MINDAVATION, a company providing project management training, consulting, keynotes & coaching services throughout North America, Europe, the Middle East and Australia.

Here is a précis of Bob’s guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.

  • An eager sponsor willing to conduct frequent reviews and evaluations of the evolving product.
  • Ambitious, knowledgeable and available business representatives – The Agile process is purposefully collaborative.
  • Minimal time to verify product viability: its power comes from its ability to produce quickly, adjust consistently to new knowledge and business change but only if the learning can be understood, interpreted and absorbed quickly.
  • Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
  • A willingness to consider a very different approach; the ability to invest in a different work and management approach is necessary for the project stakeholders.
  • The ‘DNA’ to deal with a bit of ambiguity. Priorities are consistently reassessed and work sequences changed.

The full article can be found at http://www.mindavation.com.au/articles/may10_intellections3.html

Bob’s approach is closely aligned to the ideas discussed in Mosaic’s White Paper on Project Strategy; see: http://www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf; one approach to every problem seldome dilivers optimum outcomes.

8 Comments

Posted in Agile Ideas

Tagged , , , , , , , , ,

IT Business Sued for US$300 million+

Posted on May 6, 2010 by | 4 comments

The IT industry is moving ever closer to mainstream contracting and vendors will be sued for non-delivery. Construction and engineering companies have been used to litigation over the non-delivery of contractual obligations for well over 100 years. Following the BSkyB v EDS judgement, the IT industry is now firmly in the same boat!

Earlier this year, the UK High Court handed down its decision in the long running case of BSkyB v EDS (now owned by HP) with the damages awarded against EDS likely to exceed £200m (US$300 million). The judgement will be appealed but stands as a warning for all IT vendors world-wide.

The dispute concerned the failed implementation by EDS of a new customer relationship management (CRM) system for use in BSkyB’s Scottish call centres. The project did not go well. After numerous key deadlines had been missed and various attempts to rectify the situation had failed (including re-planning delivery of the project by signing a ‘Letter of Agreement’ to supersede the primary contract), BSkyB severed its relationship with EDS in 2002 and completed the project in house (at a reported cost of £265m).

Litigation ensued, in which BSkyB made claims of, among other things, deceit (fraudulent misrepresentation), negligent misstatement and breach of contract by EDS. Despite EDS arguing that the project was derailed by the inherent risks in an IT project of this nature and BSkyB’s ‘vague and shifting requirements’, EDS was held liable for fraudulent misrepresentation, negligent misstatement, and breach of contract.

This decision highlights the fine line that must be trodden by service providers in promoting their offerings whilst pitching for jobs. Above all else, service providers should ensure that during tender processes they do not exaggerate their capabilities and should conduct thorough, documented assessments of prospective delivery timing before making any representations. Reliance on inherent risks in IT projects is unlikely, in itself, to be sufficient to substantiate any failure to meet representations “made by the sales guys”.

Welcome to the ‘real world’ guys…… See more on the judgement

4 Comments

Posted in IT Project Management

Tagged , , , , , , , , , , , ,

Project Management 2.0

Posted on September 27, 2009 by | 5 comments

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

  • Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
  • All good project management is based on collaboration.
  • All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
  • Access to information is vial when and where needed.
  • Open and effective communication is critical.
  • Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
  • Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

  1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
  2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

5 Comments

Posted in Agile Ideas, General Project Management, IT Project Management, Project Typology, Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , , , ,

Thoughts on Agile

Posted on September 20, 2009 by | Leave a comment

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Leave a comment

Posted in Agile Ideas, IT Project Management

Tagged , , , , , , , , , , , , , , ,

Agitating Agile

Posted on August 19, 2009 by | 10 comments

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

10 Comments

Posted in Agile Ideas, IT Project Management, Stakeholder Management

Tagged , , , , , , , , , , , , , ,