Ba   why development projects fail
Upcoming SlideShare
Loading in...5

Ba why development projects fail






Total Views
Views on SlideShare
Embed Views



1 Embed 2 2



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Ba   why development projects fail Ba why development projects fail Presentation Transcript

  • Testing and the BA Jean-Francois Bilodeau | The Smarter Everyday project is owned and operated by CTE Solutions Inc.
  • About J-F ● 20+ years of professional development experience ● Certified in ITIL, PMI ● Certified in Java, Delphi, C# & other ● Practical BA and project management experience
  • Overview ● Let's talk about: – – – – – Why projects fail and succeed Activities that BAs should do Integrating BA with the development projects Dealing with changes Testing
  • Caveat! ● ● This is a descriptive presentation—not prescriptive No magic potion or silver bullets
  • Why Projects Fail? ● Is it because of: – – – – – – – Poor leadership? Poor requirement? Lack of technical skill? Poor communication? Client changing their minds? Changes in business? Changes in technology? ● List is not comprehensive ● First four are internal and can be controlled ● Last three are external and must be managed
  • Let's flip that around...
  • Why Project Succeed? ● Is it because of: – – Good requirements? – Good technical skills? – Good communication? – ● Good leadership? Managing changes? 'Good enough' is good enough
  • What can a BA do about it? ● ● ● ● ● A BA plays a leadership position (yes, really!) BA is responsible for requirements Technical skills may not be necessary for a BA, but are handy BA is all about communication BA must be responsive to changes
  • A BA by any other name... ● The role of a BA can be synthetized into two distinct responsibilities: – – A BA is responsible to elicit and understand requirements A BA is responsible to communicate and validate implementation of requirements
  • “But wait! That's not how we do things!!?!” ● Yes, I know – Every development team is unique – Every development endeavour is also unique ● Are you a BA by name or by function? ● What is under your control or influence? ● What is outside your control or influence? ● Write it down!
  • My BA Control Sheet What can I control I can start by creating such a table... What can I not control
  • How can I help my projects succeed? ● Know the difference between poor, good and great requirements – – – ● ● Poor is of little to no value to the development team Good provides value to the development team Great provides immediate and measurable value to the development team A 300 page requirements binder does not equate to great requirements Good enough is often synonymous with great
  • How can I help my projects succeed? ../2 ● Prioritize! – ● Do you know what your client considers important about the endeavour? – ● Spend effort on high-value and high-risk requirements before low-value or low-risk requirements Is it in writing? Do you understand what are the risks? – If not, ask!
  • How can I help my project succeed? ../3 ● Requirements should not be locked away – – How easy is it for your development team to access the requirements? How early will they have access to the requirements?
  • So, to succeed: ● The BA needs to create great requirements! ● Easier said than done... – How do I know my requirements are correct? – How do I deal with changes? – How can I ensure that the client is getting ROI?
  • Does this look familiar?
  • The Waterfall Model ● ● ● ● ● What's wrong with this picture? How can we assume that requirements are correct from the very get-go? Any flaws in our requirements will trickle down Flaws might only be discovered late into the testing phase Sounds familiar?
  • Origin of Waterfall Model (unfortunate) ● Popularized by the paper ―Managing the Development of Large Software System‖ ● Published in 1970 by Winston W. Royce ● Never used the term Waterfall ● Argued against the waterfall model
  • What Wiston Meant
  • In other words... ● ● ● Software is not is 'grown' It is dangerous to assume that requirements can be gathered and correct in a single pass It is dangerous to assume that testing needs to be performed in a single pass
  • Grown...Not Built ● Houses are built. Roads are built. Bridges are built ● Software is grown ● No two house or road or bridge can be built the same – – – ● ● Designs may be shared Different terrain, material, etc... Once a bridge is build, it cannot be copy-pasted Developing software is more akin to designing a house than building a house, road or bridge Once software is written, it can be copied and pasted
  • Grown...Not Build ../2 ● The BA plays the role of the architect – ● Just like architectural drawings give a sense of the final product, the requirements paint a picture of the finished software – ● (Not that of the technical architect!) The requirements are not the finished product! Until the product is complete, it is difficult—if not impossible—to fully test the requirements
  • Would you buy a car if... ● ● The dealer got you to fill out a questionnaire and chose the vehicle for you? The dealer provided only a rough drawing of the vehicle? ● You had a chance to sit down in it and test drive it? ● The same applies to software
  • How do you test requirements? ● With working software ● With the client ● Early ● Often
  • How do you test requirements? ● Get to the 'test phase' as quickly as possible! ● Prioritize base on value and risk ● Stop using the waterfall
  • Stop Using the Waterfall ● ● ―How can we develop software if we don't have requirements??!?‖ You do not need all the requirements before you get started – – ● Not even most Not even a lot Work with the development team as a unified whole
  • BA and the Development Team ● ● ● ● The BA is an integral member of the team The BA is the 'interface' between the client and the developer The BA is involved from the beginning to the end of the project There should not be 'BA/Development Team' dichotomy
  • Moving Beyond the Waterfall ● It's OK to do work concurrently!
  • Modern Development Methodology ● It's not just a good idea—is the norm ● Commonly called 'Iterative'
  • Iterative Software Development ● ● ● ● Work in time boxes Goals defined before the start of an iteration Goals are not limited to implementing features Goals can include: – – – Work on requirements Update/review our understanding of value/risk Prepare for testing, test and report on test
  • An Iteration End Start Define Goals Iteration Review (Goals Achieved?)
  • Are You Doing Iterative? ● Most development teams 'claim' to work in an Iterative fashion – Do your iterations have a written list of goals? – Are those goals developed with the team? – Do your time boxes have a start and end date? – Do you respect the start and end of your time boxes? – Were any tests run during your iteration? – Where are your test reports?
  • Iterative Development and the BA ● BA needs to be involved from start to finish ● Multiple incremental deliverables ● Client gets a chance to test-drive the product early ● Client can provide feedback and validation early – But what if the client changes their mind??!?
  • Software Development and Change ● ● ● ● How many BAs have ever worked on a project that required changes to their requirements? How many BAs have ever worked on a project that required no changes to their requirements? Change is not an exception—it's normal! Remember: It is difficult, if not impossible to know everything from the get-go
  • Dealing with Changes ● Change is a reality in the software development field – ● Otherwise, would we have a job? :) It's not a question of protecting against— or resisting—change, but managing change
  • How to Deal with Changes ● ● Agile Project Management Developed in 2001 by 17 software developers ● Integrates naturally with iterative ● Agile is a philosophy—not a method!
  • Agile Manifesto: ● We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – – – – ● ● Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more.
  • Agile and Iterative ● Two separate approaches ● Integrate naturally ● Spread from software development into most project management disciplines
  • Caveats! ● Agile and Iterative is not a free-for-all! – Requires discipline ● Requires good leadership ● Test, test, test
  • BA and Testing ● The BA is not the tester ● The BA is accountable for the testing! ● The BA works with the test team and ensures that they can and do the tests
  • BA and Testing ../2 ● Do you: – – – ● have a test team? have a test plan? have a test lab? If not, are they on your iteration goals?
  • In summary... ● Prioritize based on value and risk ● It's OK for the team to work in parallel ● It's OK to start writing code while requirements are begin gathered ● Change happens and it's normal. Manage it ● It's OK Necessary to start testing as soon as possible
  • Homework ● Write down what you can and cannot control ● Identify what your client considers value ● ● ● Identify risks that would put the endeavour in jeopardy Write down short term goals that you need to achieve Commit to a date for the above goal and review them when that date rolls around
  • Final Wisdom Write a list of short-term and long-term goals you would like to achieve as a BA then Take small, incremental steps to reach those goals
  • TECHNICAL Microsoft VMware Cloud Computing IT and Cyber Security CompTIA Java ProgrammingLanguages Novell UNIX Training with impact MANAGEMEN BUSINESS Change Management TOGAF T Enterprise Architecture ITIL COBiT Agile and Scrum Business Analysis Project Management Communication Skills Leadership Skills Negotiation Skills Problem Solving Skills Facilitation Skills and many more…
  • CTE Solutions Inc. - Ottawa 11 Holland Avenue, Suite 100 Ottawa, Ontario, K1Y 4S1 Tel: (613) 798-5353 Toll Free: 1 (866) 635-5353 Fax: (613) 798-5574 CTE Solutions Inc. - Toronto 77 Bloor St. West, Suite 1406 Toronto, Ontario M5S 1M2 Tel: (416) 284-2700 Toll Free: 1 (866) 635-5353 Fax: (416) 284-6797