locked
Small Team Development - Educating Stake Holders RRS feed

  • Question

  • Hi Guys,

    This is really a question about project/life cycle management, I appologise if this is not the correct forum, however it seems the best place to find good knowledge on these matters.

    I currently head up a small development team, Myself, and another developer, sometimes another 2.  We are an internal IT department team, for the most part we develop web applications, to which end I have to work with the domain experts on the concept, produce the logical design, and lead the development on the physical design, whilst in effect managing the project.

    In your experience, in such a small team what methodolgies work well?

    Our main governing factor is always time and costs, the company was not a technology company, but is rapidly becoming totally web based, I constantly face challanges with the directors based around time scales which leads to a lot of high risk developments, and painfull code and fix cycles.

    In the past they have outsourced to a lot of cowboy outfits who complete developments very fast to a few lines of text functional spec, and provide a cowboy coded solution with no documentation, very little testing and no standards.  I am constantly being expected to deliver to the same time scales and the risks are getting higher and higher as standards are dropped to accomodate unreasonable demands such as 'over night' direct to production developments based on little more than a phone call.  I object but I am constantly told, 'Just do it'.

    I really need to impliment a methodology that is light weight, but involves the stake holders so that they can understand how the project is developing, and the importance of process.  It is a requirement that this process could be presented to non-technical stake holders, and would help them to understand the importance of the entire process, analysis, design, development, testing, implimentation and the factors surrounding successful maintenance.

    Formal methods of analysis fail, as before any documentation has been completed the requirements have changed, they move so fast that you could never complete a formal analysis.

    I tried to impliment an agile methodolgy using Version One, which is story based and works on developer trust, with short iterations to try and accomodate the ever changing domain, however this soon become so agile that it was almost pointless, it was just being used as a task list.

    I am begining to dispair as to how I can control this situation or convince the stake holders to slow down!

    How do I educate the existing stake holders?  What process should I be using?

    Love to hear your opnions.

    Thanks.






    Saturday, June 28, 2008 10:28 AM

All replies

  • Sounds like the right approach, I think you need a (or wear the hat of) a product manager to properly

    decide the business benefit of the available stories in order to prioritize them both for development and in terms of agreement with the stakeholders. The key here is to make the stakeholders understand the importantance of the outstanding issues to the business as a whole rather than to their own departments...a lot easier said than done, you need the backing of the business to do that. If that's not there then you'll be hitting your head against a wall.

     

    Sunday, June 29, 2008 2:35 PM
  • Wow, can I relate, I'm in the exact same boat.  We have tons of windows/web legacy apps.  Bottom line, IMO, is that what we (and you) are trying to effect is a cultural change.  The stakeholders are not accustomed to having to be actively involved in projects, they take the Nike approach of "Just Do It", and they've been taken to the cleaners by various "Cowboy Outfits", as you so aptly put it.  My team spends a lot of time cleaning up what the Cowboy's horses left behind.  I'm fortunate in that we now have a PM who is implementing an SDLC process and we're slowly working towards running this operation like a real IT shop.  Progress is not easy, or fast, and we may ultimately loose the war. 

     

    Among my challenges are content management.  I will likely have to implement some flavor of Agile as well, to accomodate ever-changing business rules. 

     

    More important than methodology, IMO, is finding the right people, especially developers and business analysts.  I've quit trying to blow sunshine when I interview developer candidates, because I don't want them to have any illusions as to what they're getting into.  We're not state of the art, the challenges are more cultural and analytical than technical, they will not get to sit in their cubicle and code from well-written requirements documents.  On the positive side, we have tremendous opportunities to help improve business processes and implement new technologies and architectures, something developers often don't get to do in bigger IT shops.

     

     

     

    Sunday, June 29, 2008 5:00 PM
  • Your comment that the story based solution became so agile as to be pointless seems to indicate that product management may not be as strong as it could be.

     

    Perhaps the scrum approach of a product backlog would be useful to communicate to the business the functional changes you are putting into effect.  The business can then prioritise them.  Scrum will also help ascertain problems quickly and give you some metrics for better estimating.

     

    User stories seem a good idea coupled with scrum as well.  I have implemented this in organisations to good effect - but perserverance is requried and buy-in you need to convince senior management of the business benefit.

     

    From the perspective of the development team I would look into test driven development (TDD) to shorten the development/testing cycle.  Contiuous integration may help to speed changes by finding defects faster.

     

    These may be big changes for your environment and it is best to take small steps and get one thing working well before you take another step.

     

    Process models should be developed and implemented with the environment in mind - what works in one environment for one team may not work for another team or environment.,

     

    In my experience continuous improvement is better than 'big bang' implementation.

     

    In summary I think a combination of Scrum, Agile and extreme programming may be useful along with the most up to date tools.

     

    hope this helps.

     

     

     

    Monday, June 30, 2008 9:55 AM
  • Educating stakeholders is not a matter of methodology. It is aall about showing them where their interest is. Which often means showing them what they loose by acting the way they do.

     

    In your case, your maintenance & support costs are likely to rise soon, if not already the case. And you'll probably encouter one or more production crisis due to critical bugs that should have been detected by thourough testing.

     

    The pressure will end up on your shoulders, but once the fire's over you'll have material to prove your point and can fire back with propositions for a better development process.

     

    HTH

    Monday, June 30, 2008 5:47 PM
  • I agree - my previous post only addressed the process model that could help in your developments (your second question).

     

    I skimmed over the need to educate the stakeholders as this is a lot harder :-).  Agile methods can help here because the customers are more involved, and progress and challenges are communicated more transparently.

     

    However, in my experience, the only thing that convinces stakeholders that something is worth doing is the result - in other words, do we save money by doing this? 

     

    This is hard to measure and there are many factors.  These factors are dependant on your environment but may include; customer satisfaction, time to market, product quality, retention of development staff.

     

    Agile methods place importance on open communication, customer satisfaction and stakeholder involvement.  XP places importance on product quality.

     

    In most environments improving levels of customer satisfaction would help you win over the stakeholders because it should improve customer retention, leading to improved profits.  Involving the stakeholder should help because the process is more transparent and stakeholders would have more confidence in the develpment teams ability to deliver.

     

    Therefore, as __no name__ states, the only way to win over the stakeholders is to show them the return on investment from your development method.

     

    This means that you need to be aware of what is important to the stakeholders, how they communicate, what form of communication they are responsive to.  

     

     

    Monday, June 30, 2008 11:04 PM
  • I agree that Agile processes have more stakeholder involvement, but as I understand your problem is the getting the stakeholders engaged.  After they are engaged then you can follow any process that would fit your shop.  Currently, they just want to throw the fire and not want to be involved on how the fire is put off. 

     

    One way to show the stakeholders to hold on to their stake is a shocking them.  Basically collect and produce the data and opportunities lost by following the current madness.  For example, a quick overnight change that had a downtime for couple hours, or your shop becoming revolving door where it is difficult to develop and retain the talent, etc., or how one stakeholder's request washed out some other stakeholder's request. 

     

    Also send out monthly reports.

    an ex-coo of an internet pioneer said, he was faced with a similar challenge in his job.  So he started creating all the bug reports, work requests, production downtime reports and categorized them based on line-of-business, sent out to all the involved parties, SLTs, etc., on a monthly basis.  Also, a monthly meeting to discuss those reports.  This got the stakeholders engaged and grounded them to follow processes.

    Wednesday, July 2, 2008 5:56 PM
  •  

    Hi,

     

    I head up the development department for a company that started out in a similar way, producing assets that did not rely upon IT.  As the company grew, it became more dependent upon IT.  Now without IT, the business would find it very difficult to stay in business. 

     

    This situation seems to occur as a company transitions from a small business through towards being a large corporate.  Whilst the core business evolves, people's expectations do not, unless actively engaged in the problem.

     

    I don't believe that this has a lot to do with methodology, and more to do with managing expectations of your stakeholders.

     

    The situation I find most risky, and difficult to deal with is managing the business' expectations, and being able to communicate the need to do things properly.  Delivering a good solution with a meaningful architecture is simple once the expectations have been set.  You deliver functionality to milestones, and stakeholders are generally happy.

     

    There's a certain amount of smoke and mirrors to the process of expectations.  If you're in charge of a team, and fully empowered, then you should be setting development time (which includes anaylsis, design, development, and testing)  If you go and ask the business if you can do testing, you will get a fairly obvious answer, don't bother if you can do it quicker.  Instead phrase the question properly, something that addresses the following question, "would you like to develop this solution in record time, of 2 weeks, do no testing, then spend the next 6 months to a year fixing it, or instead take 2 months developing the functionality properly?".

    The smoke and mirror come in when you consider what you think is included in development, you can "hide" certain activities within other activities.  Don't ask if you're allowed to do it, just do it, if it works, do it again.  If it continues to work, tell your bosses what you've been doing, and show them the positive result.  I think agile software is as much about being agile in your approach as it is in use this or that methodology.

    Obviously there are always reasons to be flexible, the business wants cashflow, which indicates immediately that it is not a big business.  You want to be able to do things properly and move the business and your career forward.  Your challenge is to bring these two views in line.  Can you achieve that by scoping an iterative solution where the first release allows an immediate return of revenue, then scope future iterations to add the other stuff?

     

    You have probably seen the triangle of resources vs time vs features.  That is where the problem lies.

     

    If an agile project becomes a task list, then the methodology is not at fault, only the way it is, or in this case is not being executed.

     

    Iterative development requires the agreement of a backlog, or list of features to implement during that iteration.  Once the iteration starts, that scope is not to get bigger, but realistically may get smaller, and features be descoped due to situations beyond your control.  The features in the list should go into a product backlog, a list of features that the product requires.  From this product backlog you should pick features to implement for the iteration, and deliver them properly.

     

    I think that you definitely need an iterative, agile approach, since you clearly define that the domain changes frequently.  If iteration to iteration, a feature changes, you have delivered that functionality that was requested.  If you then map out the frequency of changes, the time taken to make those changes, the resources involved, and thus an associated cost, I can bet that those rapid changes will slow down, and in a very short space of time.

     

    In terms of a project management methodology, if you didn't recognise it, I like SCRUM.  Think it's the most realistic, gives the best results.

     

    You have to get the process of how to do these things correct before attempting to use the methodology, as it sounds like what you're doing with 'agile' development is in the same manner as what gives agile development a bad name.  It is seen generally as being 'ad-hoc'.  No development project should be like this.  You should still plan, document, develop, test, train, handover with each iteration.  There isn't a shortcut to this.

     

    You can't shortcut testing, if you don't test everything, can you guarantee that the software actually works?  No!

    If you don't design properly, can you guarantee that the project is scalable, maintainable, and performs appropriately.  No!

    If you don't document, or document at the end of the project does that mean that the people involved in the project know what you have been doing, and what you are going to do?  No!

     

    I suspect a lot of your problems also come from the fact that nobody knows actually what you are doing, they don't have a list of features to pick from, an approach that makes sense to them, so they get involved, and micromanage the project.

    Whilst that situation is occurring, you basically are not able to do things properly, since it is not totally within your power to control the end result.  Thus the interferer needs to either accept responsibility for the outcome completely, or back off.

     

    Just a few ideas to get you started, obviously there is a lot more to it, but you need to think more in terms of the business, and them saying, "What is in it for me".  Answer the question successfully, and the problems should go away.

     

    I hope this helps,

     

    Martin Platt.

     

    Thursday, July 3, 2008 5:49 AM
  • Hi Gavh,

     

    You have asked a very good question. I am also facing this from quiet some time.

     

    This always happens in Non-Technology companies where stakeholders take decisions without caring technical implications and costs invloved. You have got very good responses to your question.

     

    You are using agile methodology that's very right. I am also heading a product team of 8-10 peoples. In my case same issue happens, requirements were never settled or stream lined. Business always suggests chanegs to the original drafts which again is never properly documented.

     

    What i'll suggest you is you can recommend a Project/Product manager for your projects. He'll take care of dealing with management and explain them the technical issues and costs involved or the right path. You can coordinate with him for the issues/concerns.

     

    This will make your life easier and you can concentrate more on technical points and quality delivery.

     

    Another point i would suggest is maintain a good rapport with the top management. Wherever possible try to educate them with technical processes and standards.This can take its own time.

     

    The best solution at this moment is recommend a project manager to manage the project and you tackle the execution part. I think this will make your life little easier.

     

    Let me know your views.

     

    Regards

    Hrishi

    Thursday, July 3, 2008 8:01 AM
  • Hello,

    You ask about methodology, should you use some form of Agile, or XP or whatever, but, from what you have said, your problem has nothing to do with methodology. No matter how you try to develop the apps faster and make them work properly you will never find a way of delivering the goods in an environment that includes “unreasonable demands such as 'over night' direct to production developments based on little more than a phone call.”

    You go on to say you need to “involve the stake holders so that they can understand how the project is developing, and the importance of process.”  You further say “It is a requirement that this process could be presented to non-technical stake holders, and would help them to understand the importance of the entire process, analysis, design, development, testing, implementation and the factors surrounding successful maintenance.” At the end you ask “How do I educate the existing stake holders?”

    I would suggest your stakeholders are not interested in “the importance of the entire process, analysis, design, development, testing, implementation and the factors surrounding successful maintenance.”  And they certainly are not employing you to “educate the existing stake holders”.

    As several of your other correspondents have observed you need a project manager, but I get the impression from your tone that you are not in a position to insist they employ a project manager: in which case you need to develop some project manager skills pretty quickly.

    Here are some ideas:

    Speak to your stake holders in the language that they use, in the language they understand, be interested in making their life easier. Look at everything from their perspective and much of the resentment and contention you communicate in your post should start to evaporate. Get the feeling, and communicate the feeling to them and everyone else around you that “we are all in this together” and “we are all working to the same goal”. Remember the feelings you had on that first day when you started the job. Remember how enthusiastic you were. Recapture that spirit if you can and communicate it to everyone else.

    Look for project management information on “how to manage change” and especially “how to manage user expectations”. You say the “main governing factor is always time and costs”. So this is the language you need to use. Think in terms of “cost benefit”. Show your stake holders how their return on investment would be greater if they provide the time to deliver a fully baked system, rather than something half baked, knocked up overnight that falls apart the next day. If your business relies on selling stuff to customers think in terms of “customer loyalty”, “customer care” and “repeat business”. If you are a service company look for ways of translating what your software does into better ways to deliver the service, or, better still, cheaper ways to deliver the service.

    This is not the place for a seminar on project management, but let the experience of a lifetime managing IT projects crystallise into a single idea. Get your stake holders to trust you. If you can do that most of your problems will vanish. You get people to trust you by always doing what you say you will do and delivering the right goods at the time you say you will. Unfortunately getting people to trust you takes a while, so hang in there, get some project management skills and the future should be bright.

    Good luck!

    Thursday, July 3, 2008 5:00 PM