Annette KesslerQA Analyst| Seattle City LightBrier, Wa, United States
The question was posed: Everybody seems to want it faster! Yes, but what have you done to crash a timeline without crashing the project?
What has worked well for our project team is to pick a project suitable for Agile development and to do activities concurrently instead of waiting for handoffs. For example, during requirements gathering and clarification, we're already thinking about the impacts to design and testability. During development, the QA has access to the prototype and can influence design choices. User experts are committed to being available and responding quickly when asked for input.
Co-locating teams for easy communication means you can ask a question across the aisle and easily share exhibits, instead of taking time to compose a clear email.
We continue to follow our SDLC processes, which give us a common understanding of what the next steps are, when milestones are comleted, and team members can make assumptions about how things have been done.
You want to be fairly certain it is a projec you're committed to completing, even if you scope it down, because you're committing a bigger time investments earlier in the project with concurrent activiites.
I really enjoy the rapid development and find that we have less work in our queues and the details are fresher in everyone's mind when questions come up. Saving Changes...
Sort By:
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Annette,
Excellent post. For many of the reasons you so well cited and summarized, we are seeing more and more organizations embrace Agile - iterative development, scrums, etc. And yes, everybody wants it faster. I would only add that many of us want it better too...! I hope we hear from other Agile enthusiasts. Cheers,
We are an environment that is very young in Project Development - years of handling similar yet unique projects almost as if it was the first time we have ever done them.
My past life included establishing very formal methodologies - my present is a blend of past and present and is actually ideal for agile.
The first two thoughts that cams as additional to the other great posts were - (1) get the entire team sitting together or working together frequently. Taking time to meet face-to-face is counterintuitive to many who feel email and voice conferences will speed things up. My experience shows that being face to face ofter finishes the race first (kind of a tortise and the hare approach). (2) Instead of adding resources, a prject can often be sped up by removing resources - it is imperitive that, in this situation, the resources have the proper experience and influence within an organization but this can work very well.
In regards to removing sign-offs/approval which can slow things down, I have also found the following effective when needing a lot of signatures: Walk the approval document around - starting with those who will sign with little to no resistance. In some cases I have actually had the project team sign individually on the approval when not required - it's a tad psychological but if someone sees the comittment from others, that's often enough to sway those unsure. In these cases, it is best to make sure what is getting approved deserves it - if you use this technique to get approval of something that shouldn't you likely won't be able to do this twice (fool me once... comes to mind).
Hope this is of interest to get faster and get it done right!
Joel Saving Changes...
Paul ZembrzuskiProject Manager| Las Vegas SandsNewport Beach, Ca, United States
Terminology gets ugly quickly. In the right environment Agile development "iterations" can be very productive. Crashing a Timeline or schedule usually refers to ADDING resources. Doing work concurrently (fast tracking) is very different from crashing. So this discussion might be better labeled Compressing the Timeline or Schedule. Minor point but helps to set the stage for the discussion. Saving Changes...
Bipin Lekshmanan PMPProject Manager| Wipro TechnologiesEdison, Nj, United States
Good post. Joel's techniques to gget things moving from amethodology standpoint are laudable. Saving Changes...
Rob MartinConsulting (Contract)| Microsoft (Thailand)Lam Luk Ka, Pathum Thani, Thailand
I thought I'd stick a few cents worth in on this discussion:-
Before thinking about "Crashing" or "Reducing" a timeframe on a project you have to get two things straight...
1. Air Cover from your Sponsors and immediate Management
2. Total buy in from the stakeholders.
Without these you'll just be a wave crashing on the shore trying to count grains of sand.
Rob Saving Changes...
Richard HowProgramme Management Consultant| How Associates LtdHarthill, South Yorkshire, United Kingdom
The big danger with crashing the timeline comes when you cannot find a way to make the work fit the time available without someone going against their better judgement and agreeing to an unachievable delivery date.
its important to remember the following
"its easy to fool someone into accepting a deadline, its quite another thing to get them to deliver to it"
Theres really no point in crashing a timeline to the point where it is unachievable Saving Changes...
Here are a few I have found …
Make sure everyone is informed early and continuously weeks in advance as to their next tasks, both actual work and approvals.
For approvals, inform and status management the effects late approvals will have on the project progress prior to even sending out the documents.
Get management to accept passive approval (it is approved if no response in x days) in some cases.
Take a long hard look at the documents you create. Most were developed to document that work was done and get paid for, not designed to be efficient. Somehow over the years people have come to expect literary works of art not technical working documents. A Requirements document is notoriously inefficient. Get rid of the large amount of literary verbiage of paragraphs and change to a simple picture and list of bullet points of what it does and does not do. This will help the people reviewing the document with ease of understanding and help developers by not having to interpret paragraphs into tasks. This approach will also let you send out documents for early review as there is less formatting and grammatical issues to contend with.
Develop documents at the end of the project after there is agreement that they are needed, wanted and add value.
Annette, while I aapreciate your work but the points raised by Rob and Richard are worth considering. We like Agile but we cannot go beyond reason at times. But still I get your point and vouch for it. Saving Changes...
Ahmed Fouad SedkySenior Claims Consultant | Systech CanadaToronto, Ontario, Canada
Annette, excellent post, what about you start one that tackles the same issue for construction projects, if you faced similar situation on construction projects. Saving Changes...
