How do you find what you don't know about roadblocks in your development process?
Continuous improvement is a given for any business today and I am curious how you go about finding the areas that are roadblocks to faster and more predictable product development. I have successfully used one on one interviews with a broad cross section of the new product development team to uncover what I call "unknowns"; the development process issues that are not generally known to the team.
Do you formalize finding what you don't know about your development process?
What tools and methods help you uncover the hidden roadblocks to maximum productivity?
Do you believe unknowns exist?
Clarification added November 23, 2007:
Good inputs on the roadblocks that have been found. To clarify, what I am looking for is how the roadblocks were discovered? Do you at some point say "There is probably something that is inhibiting optimal team performance, I don't know what it is or even if it exists but I need to check and find if there are any roadblocks." Do you do this and if so how do you go about it?
Good Answers (4)
Wolfgang R
Dipl.Ing. (MSc), PMP, CSM; Specialized in Project and Requirements Management for the Telco Industry (OSS/BSS).
Best Answers in: Project Management (3), Product Design (2)
Without trying to read between the lines of your question, what came to my mind spontaneously was: Ask, ask, ask! And don't afraid of the answers. Don't expect others know what you know or expect what you expect. Sometimes people are afraid about the consequences of their answers and then you will most likely not be able to uncover hidden roadblocks, but the trick there is to ask more than once, maybe slightly differently.
However, the time part is a challenge. Wasting someone's time by asking too much as opposed to asking the right questions and saving time in the end is an art. The balance between only annoying people by being paranoid and being vigilant is hard to find. However, trust relationships help a lot. People will come to you then.
To summarize this more general response: Ask, don't be afraid of the answers, don't presume, try to get different opinions and be aware of the anxiety of people.
The only formalized means of identifying 'roadblocks' in a process that I am aware of is to document or flowchart the process and timeline and investigate anything that looks abnormal, doesn't quite match up, etc.
I think 2 key elements in quickly identifying roadblocks are a fresh perspective and liberal use of the word 'why?'. People that have worked with a process for a long time often just take what they do for granted and wouldn't recognize a roadblock if they ran face first into it. They also tend not to question it because "we've always done it that way".
Someone unfamiliar with a process is more likely to ask what appears to be a stupid question and identify your areas for improvement. An external consultant has advantages of familiarity with industry standards and would be neutral in his/her findings.
One word of caution; if you ask people what they do and why, you probably want to make sure they understand your goals as they may be defensive and protective of the status quo.
Sharon T
Inventory and Forecasting Manager at YSL BEAUTE
Best Answers in: Corporate Governance (1), Wireless (1), Using LinkedIn (1)
Brown Paper process, prior to starting to make the change find exactly what needs to be changed. Simple yet effect tool is to find a very large room get a very large roll of brown paper layed out on the floor. Get together all the people involved in the process from start to finish and map out on the brown paper the complete process chain. Once this is done you all review what has been mapped out and using the Project Managers key tool (post it notes) mark out where the current roadblocks are, highlight all value adding processess in the chain plus identify the waste areas.
Once you have done this you can then start to create a Blue Print Paper of how you want the process to work going forward using the value added only and discarding the waste.
Bob B
Product Development, Operations and Quality Executive and Consultant
Best Answers in: Organizational Development (5), Product Design (4), Change Management (3), Planning (3), Labor Relations (2), Project Management (2), Staffing and Recruiting (1), Business Analytics (1), Manufacturing (1), Supply Chain Management (1)
Hi Jeff,
I'm a management consultant who helps firms remove the roadblocks that gate their product development performance. From my experience, typically the gates cannot strictly be removed by "process" optimizations. That may be what they want but a great paper process doesn't make up for siloes, team issues, leadership stuffing too much into the development pipeline, people confusing goals and commitments and the myriad of other things that involve people and exists in many organizations. What I tend to find is that there are systemic issues at the intersection of people and process that are the high leverage points to enable significant improvement.
That recognition led me to take the following approach. First, I developed a trademarked framework and methodology for systematically going through the "soft" and "hard" aspects of a product development system from the tactical and project levels to the strategic and portfolio levels I called "Who What How" first looking at all the people related aspects, then the work distribution, then the different processes employed. I compare the findings against an accumulated set of "best practice" reference models (from experience, case studies etc. - these continue to evolve) and then synthesize the the gaps, taking into account the uniqueness of the business into leverage points for improvement. What I do takes experience but is straightforward and works. At a high level a big difference between it and internal continuous improvement is the perspective from outside in objective expertise and knowledge of best practices (often from different industries) as a reference point. It is especially hard to both recognize and deal with "people" issues purely from the inside if they are systemic and gate performance. Process can be used to reinforce changes in norms and alter behavior but that's part of a change strategy once an objective diagnosis has been made. Those sorts of changes would be hard to find in a traditional process mapping and optimization exercise which presumes the "who" and "what" are fine.
I hope this perspective is helpful.
All the best,
Bob Becker
Links:
More Answers (12)
Ben R
Marketing Specialist
Best Answers in: Viral Marketing (1), Non-profit Management (1), Project Management (1), Retirement and Estate Planning (1), Incorporation (1), Using LinkedIn (1)
Absolutely unknowns exist. There are so many variables to a project that make uncovering possibilities a requirement before starting. I am in the middle of starting a company with a partner. One of the things that I am doing as I line my ducks up in a row is asking questions from my vendors and suppliers. For example I have a great attorney who is putting together everything from filing with the state to our buy sell agreements, to our employee contracts. I spent 2 hours with the attorney asking him questions about possible road blocks from his point of view. I have done that with a few dozen people. This has given me a good handle on what to expect is coming in the next few months. Also past experience is a good indicator. So trust your instinct.
Happy Thanksgiving
Pieter D
Head of Telecommunications Services & Solutions at T-Systems
Best Answers in: Ethics (15), Using LinkedIn (4), Career Management (3), Education and Schools (2), Job Search (2), Staffing and Recruiting (2), Sales Techniques (2), Computers and Software (2), Wireless (2), Purchasing (1), Certification and Licenses (1), Freelancing and Contracting (1), Mentoring (1), Personnel Policies (1), Internationalization and Localization (1), Treaties, Agreements and Organizations (1), Corporate Law (1), Internet Marketing (1), Business Development (1), Public Relations (1), Change Management (1), Organizational Development (1), Planning (1), Currency Markets (1), Industrial Design (1), Product Design (1), Pricing (1), Enterprise Software (1), Computer Networking (1), Telecommunications (1), Software Development (1)
I don't know everything, but I know who might have the information I am looking for. And if not, I know someone, who may know someone who knows it.
In the process... In any larger organization, there will be potential obstructions, also known as 'stakeholders'. People that may give or withhold cooperation or approval (I have only one formal approval step in my process, the others may for the most part be ignored if necessary), could be roadblocks, if your process requires complete cooperation or approval. This is exactly why product development must be supported by someone in higher management, or the product developer must have some usable level of delegation of authority.
I also know of people rewriting the process with each new product to be developed. In that case you are trying to reach a destination on a sailing boat without a rudder. And according to a very old proverb: "If a man does not know where he wants to go, no wind is favorable".
All unknowns can be eliminated or made dependent of assumptions that could rest on reasonable grounds. Any remaining risk can be quantified.
There is a blend of technical and soft skills required to successfully bring a project to a desired conclusion. I agree with the one-on-one in real time during the project. But you have to be careful not to take up too much of the developer(s) time. Picking up a bit of information can go a long way in understanding the future risks. Being consistent throughout has worked for me such as;
Process - make sure you have a system that incorporates all aspects of the project, is communicated throughout, has visibility at all levels, is consistent and supported by all stakeholders.
Plan - delays will happen and what you do about them will drive success or feed failure. Simply budgeting fudge factors is not the answer. If you want to pad some numbers based on knowing some individuals have been optimistic that is OK. Have alternative means for accomplishing tasks if your primary path is not cutting it.
Schedule - This is not only necessary to track progress and communicate it but an excellent tool working with development teams. As silly as it may sound it is much easier to use the schedule as the "bad guy" as opposed to saying upper management/Sales/whoever is pushing us. I have used a three tier schedule with a point of no reture milestone. For the three tiers they are; 1. Executive Overview - main milestones, etc., 2. Details - such as when difficult traces are calculated, software structures defined, etc., 3. Outside Requirements - When does Mrkt need screen shots, when is a major stakeholder back from vacation, etc.. As for the "point of no return" I sit with the responsible team sometime shortly after the start of the project but into enough such that we have a better understanding of the tasks ahead. We then evaluate our current schedule. If it is too short and we cannot rationally find alternatives within the same time frame the schedule is adjusted accordingly. But this adjustment will remain and if you need to cancel vacations, plug in weekends and long days do so. Make it clear to everyone why you are doing this such as it is strategic to the company.
Communicate - Make sure you are communicating to the team up/down/across the status and how/when/why aspects of the project. Make sure those within the team that need to communicate are doing so - if they are not then you need to do it for them - very important.
Focus - Do not let yourself or any team member get distracted. Keep focus on the Plan.
Avoidance - Avoid any negative items, including potential team members, that will not be benefitcial to the project. If you have a excellent team member but they would not blend well with the team or cannot be isolated and still contribute avoid them. My take is to talk to them first and be blunt in asking for their cooperation. If you feel it is not there - don't put them on the team. Avoid third party contributors that have not produced to your satisfaction if you can. If you cannot then budget some extra time in the schedule.
Balance - Prepare to balance everything from resouces to requirements. But keep your focus on the end goal.
All of the above is common sense - the part that has worked for is using it from start to finish. You must be an active member of any project from running the company, sales, engineering projects or any subset.
Good Luck - Mick Conley
Having brought technology products to market in several companies ranging in size from $10M - $100B, I would observe a couple of things. 'Not invented here' is a big factor in most breakout products which are, of course, the most fun. This problem is very similar to any endeavor that introduces change into an organization since many people in the power structure will be invested in the current way of doing things. Often, these same people created a breakout product or technology in years past and their success is built upon this very thing the new breakout product is trying to displace.
I have always found some guidance in classes in product life cycle I took at RPI while in a masters program there. I would say it is very important to be clear where you are in a product life cycle and be able to articulate this very clearly to senior management. Without their support, product innovation is very difficult. People seem to intuitively understand when a technology is approaching the point of diminishing returns.
Having said that I would relate a story from my IBM years. A young engineer named Marv Pittler was a group director at IBM Fishkill in the early years of semiconductor integration. Geometries were shrinking (50 microns), complexity was going up exponentially and yields were becoming very uncertain. Marv was convinced that the problem lay in the cleanliness of the process and that yields were suffering due to contamination. He could not get funding to pursue development of a cleaner environment so decided to do it anyway and hide the expenses in other parts of his budget. Marv built the first cleanroom for semiconductor manufacturing. Fortunately he was correct and yields went up dramatically. When his management found out what he had done there was little they could do but climb onto the bandwagon. Marv went on to become the site general manager and VP over the IBM semiconductor division. Sometimes it just takes balls to get things done.
Jeff,
We know there are roadblocks in a development process and therefore this is why we all look at continuous improvement of our processes. One of the many ways to finding out what is wrong is to perfectly know your process and how people deviate from it. Then you can try mapping the formal process as discribed within your procedures/charter and present it to people who use the process daily. Value map analysis can be a good tool, but do not do it alone, you need to work with people who are or have been using the process. Then, a good gap analysis can be performed with key people within your company. This will help you understanding why people need to deviate from the theoritical process and why they believe doing so help them avoiding roadblocks. Not that they do right, but they at least know there are roadblocks. You work will then be to modify your process for anticipating major issues. Somehow, within your described process, you also have to leave some doors opened for stakeholders creativity. You can not predict everything, but you need to trust the expertise of some of the people who use the process to find some solution and not being locked by the system
Hope this helps,
Christian
Other than asking, another good way to discover roadblocks is to observe. Unfortunately its much harder to observe the process and uncover roadblocks as an internal member of a team. This is because you are predisposed to justifying the reasoning behind a particular action that could be seen as a roadblock.
If you have an idea where the roadblocks may lie, then you can have someone from a similar but separate department analyze the processes in question. This way you can have an impartial person not only ask the question "why?" but also give a suggestion on "why not?".
Once you think you have your current optimal performance setup, then begin to analyze other departments for how they do things different, and if their methods could lead to improvements in your department. If you company is to small to analyze other departments, you can hire a consultant to come in and analyze your processes. You could also reach out through your network and see if you can collaborate with others to analyze each others processes to find areas of strengths and weakness.
Eva L
Business Analyst at Delta Faucet Company
Best Answers in: Using LinkedIn (2), Project Management (1)
One of the best methods you can use to identify unknown organizational roadblocks in development is to review the development estimates of newer team members. Where their estimates have been more than the actual work required by some statistically significant factor, ask for explanations and look for patterns across various projects. Additionally, ask the team members the question directly, record their answers and correlate to find significant areas for improvement.
Ralph B
Digital Product Manager at Productivity Press
Best Answers in: Business Development (1), Supply Chain Management (1)
Christian Leblanc is right in suggesting that you map your processes. We publish books on both product development and value stream mapping.
Links:
Patricia H
Director, Debit Advisory Services at Mercator Advisory Group
Best Answers in: Organizational Development (2), Corporate Governance (1), Branding (1), Positioning (1)
One of the best ways I've found to uncover hidden issues is to undertake a post-project review. I prefer handling these first with each participant group (i.e., analysts, engineers, pm's) and then with the entire team.
I also make sure that I include the sales team in this review; because often issues begin during the sales process or are buried in RFP responses.
My final recommendation is to take time to speak with the front line workers on a project. They are the ones that often fix key stumbling blocks before you can identify them.
Provide each stakeholder of the project with a means to communicate issues and roadblocks via a formal process (status report)
simply letting them choose between red, yellow, green as a status can help bring these come forward. each person responsible for the hierarchical level of reporting can then look at these alerts, and decide whether they need to be communicated to the next higher level in the hierarchy.
Shyam K
Manager Business Development at Krawler Networks
Best Answers in: Enterprise Software (1), Web Development (1)
Great question Jeff.
I would start with breaking down the quest to 'Know what you don't know' into the following actionable steps and explain by drawing parallels with an established software development process : Testing
1) Where to look?
The boundaries are well defined in testing and the testers inevitably know where to look. Although the results and findings may extend the region itself, the starting point is always known.
In the case of business processes, these boundaries though not obviously visible, do exist in the form of departments, teams, links, etc. The best way to identify the starting point is analyze historical data to narrow the scope of the quest.
2) What to look for?
Experienced testers have an idea of what bugs to expect even before they start testing.
A team of experienced 'testers' with extensive knowledge of the processes involved would be of great value to the quest. This coupled with the right inquisition procedures and tools (eg: Appreciative Inquiry) will lead you to the roadblocks faster while discovering related dependencies as well.
3) Substantiate your findings
On finding a bug, the testers identify the exact steps to reproduce it, to validate it and confirm that is not simply a spin-off off other bugs.
Similarly the roadblocks should be confirmed, maybe by trying to run a test vehicle through them, to backup and verify your doubts with substantial proof.
4) Whom to inform?
A bug tracking system is generally in place to ensure that the bugs can be reported with the necessary documentation and assigned to responsible developers.
Likewise, the roadblocks should be immediately reported to the concerned authorities as well as the responsible personnel. This entails transparency and accountability to be positively acknowledged and leveraged across the organization.
5) Ensconce corrective measures
The smart developers collaborate with the testers in the bug fixing process to ensure that the bugs do not resurface in different forms.
Similarly, all concerned personnel should be involved while identifying the corrective measures to ensure all points of view and the effects and repercussions are taken into consideration and only then can the solution be truly ensconced into the organization.
I hope my views on this highly interesting subject will be useful and all the best with your endeavor.
We find in large projects there are always unknowns and unforeseen delays.
Our best efforts are to discover the unknowns as early as possible. Constant communication and interactions with the client (we often use daily workshops or "standing" meetings) seem to work best to pull out the unknowns. During these sessions we see someone in the room get that "green" uneasy look as they put the pieces together that there is a problem.
Agile development methods of short "sprints" applied to any project with the goal of delivering business value for each "sprint" will help discover targets that will need to be adjusted and the real importance of the predefined objectives at an early stage.
