Slide Projection
Cascade – Best Practices for effective delivery of information systems in a multi-project Environment
Waterfall
Best practices for effective delivery of information systems in a multi-project environment. ©
David W. Wright
Copyright © 2008 by David Wright
This article is written for people working in companies that have an IT department to support your business non-IT. In comparison, this article is not written for people working in IT companies, from Google to someone who sells excel macros. The main reason is that I have not worked for an IT company and, although I have worked with many in the supplier-customer relationships, I do not feel qualified to write about something that has no experience. However, even companies that sell IT need any other IT to help run your business, so maybe some of my experiences may overlap with theirs.
Given that, we consider the vast majority of companies that are making cars or serving hamburgers or the provision of investment advice or any and everything else. In these companies there is a department or division full of IT "professional" programmers, project managers, analysts, testers, implementers, operators and a host of other specialists such as database administrators and network engineers. (I use quotes because professional long time professionals such as lawyers and engineers to protect the use of the word.)
The name of this group has evolved in general to the Department of Computer Science, or the same short (no "D" at the end), past names such as "Data Processing" or "Management Information Systems" appears to have vanished. As an acronym, "IT" is used interchangeably to name the department and describe the functional scope of activities of the department.
So, as you speed through the first decade of the 21st century and the next, what is the common situation that these IT departments are facing? Is likely to include:
– An assembly of information systems used by the company to monitor and report on its operations: There is always more a system, and possibly hundreds, many doing the same job as many others. Some may be decades old, some may be recent and quite new technologies, implementations of the rest scattered throughout the history of the department since the first computing machine was purchased with the wide range of technologies development and exploitation involved. (How do you read over your main computer was dead? Do you die? Not likely.) Is still the favorite The term to describe this installed base of legacy systems.
– A new high record of requested changes to the installed base of systems, covered with a long list of an error in the systems that the company is currently working around 'at a time until fixed.
– A "IT Strategy" that describes glowing terms how the two previous cases be remedied by moving to a new method or tool or an enterprise system … if the budget and resources can never be freed from the establishment and modification of existing systems
– A group of managers (or management committee or review board) which is responsible for deciding which IT work is approved and implemented: this group can be formal or informal, and can only be one person at the end, the CEO or someone he / She has delegated, since it costs money, the CFO is a common choice.
In this structure, the head of IT (CIO is the hot title, of course) plays a secretary of the committee and / or facilitation role, which is supposed to help the rest of the management in making IT decisions. This is a difficult role because the rest of the management has a fraction of view of information, most of which is a waste of time and money, with the exception of the work of each one wants to / from their own department division.
– A large number of ongoing projects is carried out, that nobody remembers when they started, and although a date has set a target without a reasonable expectation that ends soon.
– An IT staff has remained the same size in numbers, or declining, while than to be accused of doing more work than ever: "Work smarter, not harder," "do more with less". Each person is probably assigned to many ongoing projects, juggling work and trying to determine what really should be working.
The morale and overall effectiveness of this depends to a large personal measure the skills of their immediate management and more senior managers who provide some level of inspiration, and if not, sinking morale and increases turnover.
Sound familiar? Then you have the same experiences as me, and I wrote this article for you.
The premise of this paper is that situation described above may change, but usually is slow, or worse, there can be no immediate change in his department is outsourced. Meanwhile, what you can do to be "successful" in the average IT department of your company average?
What to do is deliver all applications change, and finishing existing projects so you can start new ones (there will be a new one). At the risk of sounding like a psychedelic poster, this means accepting the things you can not change and change things that you can.
What can not be changed now?
– The installed base of legacy systems.
– The accumulation of requests for changes and errors (even if you do manage to meet many of these things, there will be new ones coming to take his place, is the security employment).
– Senior conflicting priorities of the administration 'of IT.
What can change (or at least start to change?)
– The structuring and management of IT projects.
– The general management skills and specialist staff.
– Allocation staff for projects.
What follows in the rest of this article is my recipe for this change, the support of some war stories, lessons learned, and a lot of ideas to try. Even an "average firm" has some unique features, so maybe not everything in this book work for everyone, but I hope give you enough ideas for some jobs. My own fervent belief is that the visible success of IT projects can lead to softening and improvement of the things you can not change now.
Why do I think?
David Wright is a veteran of more than 25 years in the IT trenches. He started as a programmer in the central unit dominated by 80, followed by 20 years as a business analyst and architect, supplemented seasons managing the project and evidence that resources limited, it is necessary.
Mr. Wright has spent time both in operational areas delivering enhanced business systems and new, and research and development focused methodologies and tools in information system. The companies he has served in these roles have ranged from life insurance to express delivery teams leasing and financing. In business, has supported both the business operation and support functions such as finance, human resources, and even computer systems administration.
Sound good enough? If so, let's begin.
How can we document this? With Principles.
Like you, I read my fair share of IT books and articles, and each author has to decide how to best present what they are trying to communicate. One way is to describe the challenges and opportunities of interest to the reader, then document the new approach or method to solve the problems, the back of the document is the new approach or method first and then describe what the problems than solutions.
I would like to try a mixture of the two, in the context of a whole. This is not a original idea, I must admit, like many manifestos and proclamations have been used to introduce new forms of things, the Agile Manifesto is well known ( http://agilemanifesto.org/) and I am a particular fan of the Business Rules Manifesto ( http://www.businessrulesgroup.org/brmanifesto.htm .) These and others like them design the basic reasons for their existence and value they provide.
Principles can be very effective, the best I've seen have been created by Mao Tse-tung for the Chinese Red Army's new after the first ended in failure. Its main wear long war / was summed up in "a guide military sixteen characters that even an illiterate peasant can understand …
Enemy advances, we retreat.
enemy halts, we harass.
Enemy tires, we attack.
enemy retreats, pursue it. "
Effective that is, against which I hope not entirely my own where compared.
What are these new IT principles I propose?
1. There is always more work to make people do so.
2. Projects to change the whole business, so they know the first global business.
3. Using a general architecture to describe the business before and after the projects.
4. Choose the right project (s) for business.
5. Once a project is started, finish it.
6. Specialize – Each team member assigned to a project must do what they do best for the duration of the project.
7. An Architect / Analyst can generate enough jobs for two developers and a tester, the structure of project teams in this relationship.
8. It is the shipping (that matter), no homework.
9. Leave a record of what he has done, so the project does not forget if you go.
10. Models are better than text.
11. Partition of major projects months in 3 phases, which is the longest period you can plan without the possibility of a significant change of priorities, resources, etc.
12. In phase three months, the work packages for periods of two weeks, look for 2 weeks, and then design and develop for 2 weeks (2 developers), then tested for Two weeks. When the first two weeks of analysis is done, start the next two weeks of analysis in parallel with the design / development, continue to cascade two weeks periods of complete project scope has been addressed.
13. In view of many medium to small software features, the architecture used to manage and integrate the results expected in a complete system.
I consider it a work in progress so, like most inventors of new principles or practices, I have a general name to cover for now and its evolution. They are:
Cascade – Best Practices to provide effective information systems in a multi-project environment. ©
Let's take a look at what each principle means or implies, that will introduce the remaining chapters cover the principles in more detail.
1. There is always work to do but people do it.
Bordering labia, This principle sums up the reality of almost all organizations and activities, not just information delivery systems. It implies that a group within an organization responsible delivery of final results will be a copy of a work record is not over. The existence of a new "log" is in itself not a problem, it reflects the desire for an organization to solve new problems and actively manage their own improvement, the problem arises when grown in size significantly since a management perspective, , and the length of time an exchange element sits in the back-log increases so that can be measured in the number of months or years.
Therefore, we accept that there will be a delay; full disposal mean that the group provides (as IT) is redundant, or that the global organization has stalled. What to do is embrace the back-log, which is the input material and must be handled as such.
2. Projects to change the whole business, so they know the business first overall.
An endless debate in the IT circles is about the amount of IT staff need to know about business information systems are support. It is shown for each of a job advert which says previous experience in the industry of the employer is mandatory.
Is the detailed knowledge industry and the experience is absolutely necessary for a job? No.
Can a member of IT staff to be effective with absolutely no knowledge of the industry of your employer? No.
As in many such situations, the 'Yes' answer lies somewhere between the two extremes. As a pendulum, the level of knowledge of the industry vary across this spectrum, based on the specific organization, and the particular role of information; For example, analysts need to know more of the programmers, and rightly argued that testers need to know more than the analysts.
Thus, some knowledge industry is necessary. I suggest from experience, however. the investigation of several weeks in an industry is equal to the work experience of several years, as a person's experience is represented out of date by the industry changes, or too specific to the company for which he worked. This is truer today than ever, as the ubiquitous Web makes information available on almost anything with a string and a few mouse clicks.
As a result, not need to know about the company enter into a project, and will learn more as a project progresses.
In addition to this debate, however, How much do you need to know about the specific form from your employer conducts business when competing in your industry. Again, the experience, I suggest that very little or no knowledge is necessary to go into a project. The cliché that "a little knowledge is a dangerous thing" applies here. If people know much about IT of the ordinary, unconsciously may be limited when designing new solutions' business as usual have been here. "In extreme cases, this can lead to an IT staff member has the delusional belief that they know more about the business users and management systems.
Do not let deceive victims of this belief. This is the underlying hardware infrastructure and information systems that run on them. users and management systems — With the support of all strategies, policies, procedures and standards that define and control the business — will know the details of your business better than IT; your posts depend on it working.
This does not mean that all business users and management that knows everything, or that all companies operate without duplication and errors or are not things that the business does not know yet. In fact, the effective use of IT can resolve many issues such as the operation of a business, but the people and do this in support of the company, does not define the business.
Therefore, know your business to support your business.
3. Use to describe the business architecture, before and after projects.
"Architecture" is becoming more widely used a term associated with technology information. The number of adjectives applied to the term seems to have no end: "Technical Architecture", "Systems Architecture", "Architecture Business Systems "," Enterprise Architecture "and so on, so it must be important.
Why do we need architecture?
The architecture is not an end in itself; Architecture exists because things have to be built.
The architecture is necessary when building something that is not simple, in essence, Architecture identifies all the separate components of a final product and how all the components are related and bind to include the entire product.
The architecture is layered to capture and present information on the product to different audiences, from beginners / high concept to specifications.
Applied to IT, a component assembly approach is dominating the industry, from the viewpoint of software development, object-oriented real-time use of defined services, popularized by SOA. Specialized software agent is starting to help in the search and brokering services between different services for collaborative transactions.
For the average company using IT, the architecture is needed, because you need the functionality of IT focused to provide the highest current value, while trying hard to ensure that the work function ("integrate") with the following function is needed.
Note that this is the Information Systems Architecture., There are methods and approaches that are being promoted for the final grade of "Business Architecture" architecture for the joint venture, not just IT. From IT circles, which often look like an IT / IS architecture, which can be confusing. Architecture in this book is definitely on Information Technologies and Systems.
The good news is that it is necessary to devise a method of IT Architecture for your business. Many authors and vendors are already available methods. To begin, I recommend researching / adoption of the architecture that started it all, the "Framework Zachman "as developed and improved by John Zachman. Devised a framework matrix that cross-reference information from the basic concepts of abstraction levels that are used by different audiences and participants in the delivery of Information Systems.
The key benefit of the framework is that it illustrates how the concepts information can be transformed through the levels to produce components for the operation of the necessary information systems.
See under zifa.com
Zachman last two points:
– The crossing points of the concept of abstraction of columns and rows are called "cells" each cell in the group of methods or documents (artefacts) that describe the contents of the cell. Zachman does not specify which artifacts to use, or the methodologies used to create the artifacts. Things in every cell in the diagram are just suggestions.
Keep this in mind for Principle # 10.
– The framework is in two dimensions, but in reality is multidimensional, when the devices within a cell are cross-referenced to artifacts in other cells, the most obvious example vs How is what that is, what is the function creates specific events of the data.
4. Choose the right project (s) business.
At any time, the IT department of an average company is running several projects. Getting Started How were they even define as a project that should be done?
No one can really know. In more chaotic environments, projects may begin as a seed of an idea, pick up new impetus and resources if a manager or two you may see them benefit from the project. At some point, the project will bump into another, usually because they both want the same IT staff or other resources. Strong managers often can get out of these conflicts for resources with the need for your project, while others suffer from their project managers running or waiting to be canceled. Otherwise, the conflict rises to a well-known top manager has to step in and decide who gets what, and this is often the first time the senior manager has even heard of the projects.
I sat at a meeting of senior management committee where progress to date of a major project was presented and a request for a budget increase was made to complete the project. The CEO took all this in and said that this was very interesting, but given the considerable amounts of time and money spent so far, why the hell had ever heard of this project before? Next week my manager sent me to see the CIO, who accused me of giving a new process to define, approve and monitor IT projects, better known these days as "project of good management. "
So how do you choose the 'law' IT projects? First you have to take explicit decision avoiding the creation of random companies described; encourage any and everyone to suggest possible projects. An active process of strategic and operational planning also tend to drive new projects and a look top and middle managers of IT support to achieve their assigned objectives. All these project proposals ideas then become the input to a "casting" process, with the support of the means of assessing the value of a project as, but not limited to the cost-benefit analysis.
5. Once a project has started, finish it.
Even with a good process for choosing the right to implement the projects, there will be a tendency strong, if not recognized to start too many projects at once, or initiate more projects already under way before they have completed. This goes back to the split view manager senior media that most IT spending is a waste, except for their own projects. In view of several senior managers in an organization expressing these views, a natural reaction is to have at least one ongoing project to each manager, if most IT efforts are applied to projects only a few managers, the rest will complain or start looking for other options.
However, trying to run too many projects at once ends up pleasing no one, since makes no progress on the project perceptible enough to be seen as a success, so the result is that nobody is happy with his performance, even information.
Therefore, the projects must be implemented so that at least one is completed within each reporting period, which would quarterly in most companies. In large IT shops with dozens of projects, can be a percentage of your target, 10% to 20% of projects completed on time. Given the common situation of limited IT resources, the allocation of resources to a group of projects must be guided by one devoted to the realization, not priorities.
6. Specialize – each team member assigned to a project must do what they do best for the duration of the project.
This principle supports # 5. With limited resources, there is another strong trend towards IT staff have "multiple hats" in a project, especially the Business Analyst also be asked to be the project manager and / or the tester. Instead of getting more of what you are paying, you get less as an IT expert employee of an spends more time function to perform other functions would be appropriate to consult the specialist and distracted to be productive in their primary function.
At any time, and perhaps more than at present, there will be debates about which is better, a doctor or specialist. I agree that a strong general, with experience who can cover a wide range of tasks is the best resource you can have. However, these people are rare and the chances of having even one of those people in the average IT department are low. Therefore, make sure your staff is doing what they do best as possible as often as possible.
(This does not mean that people can not learn new roles in time, switching to different roles or aspiring to be generalists that coveted. However, this is the task of overall management of resources, the operational costs will take care of part of a person's productive time. This is why most methods Project management usually account for only 6 out of 8 hours can be used in real projects. This reduced availability further speaks to the value of specialization at one point in time. He also speaks of the value of matrix management, where project managers manage projects and resource managers manage "care and feeding "of valuable IT staff assigned to projects.)
7. An architect / analyst can generate enough work for two developers and a tester, the structure of project teams in this relationship.
This is really one of those "rules of thumb" that have been confirmed over time. (The amount may vary slightly from case to case, as when different levels of experience through the papers.) This relation is combined with the expertise of principle # 6 form the basis for the cascading effect on the principles covered later.
8. It is the shipping (that matters), no homework.
The end product of an IT project information system is ready to be used effectively by the company. If you can jump from 'Start' to the final product a "task", then power to you. Some people can do this, most can not. This is again where a team of specialists is more effective in Average project.
This means that the project is divided into many tasks, sub-tasks and so on. . . Once assigned a task, it is the goal of a specialist to produce a benefit / result / artifact that can be used by the specialist next to promote the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many who spend an excessive amount of content that explains how to do a task, how to collect all tasks in stages, and frequently insists that his form is mandatory for success.
What this may lead to an overemphasis on the "how" IT project tasks, to the detriment of reality to complete with due expedition. Here we see the task performed 90% for weeks, or the famous "analysis paralysis "in which a project can not seem to get past requirements. end does not justify any means, but ends must be delivered.
9. Leave a record of what he has done, so the project does not forget if you go.
If the change is the only constant, then the resources in a project will change. Risk in these changes is that the contribution of an individual for a project will be lost and that the new person assigned to the project will have to start again. This is a particular risk in "quick and dirty" projects where they produce an operating profit, but no one else can understand the code has occurred. However, if the contribution is the production of quality fittings as described in paragraph 8, there is always a point record at the time of what has been achieved so far, that can be used for new project resources to continue the project with minimal disruption.
10. The models are better than text.
I would think that at this point in time, this principle no longer requires justification. There have been at least a few years since I last saw a dense "SRD" or "SDD" document (DOCUMENT SYSTEM REQUIREMENTS, DESIGN DOCUMENT SYSTEM.) I offer my respect to people with talent Many worked hard to produce these documents through the decades, these documents for at least a step up from any requirement or design artifacts at all.
Consider what a "model" really is, in general, is a representation of a finished product in a reduced version, the engineers have been creating models of what is to be built for centuries, for reasons such as tests of small-scale problems, and present a vision of the final result can he pay for it.
At this point, however, we must abandon any other aspect of engineering physics as an analogy for the development of Information Systems. The software is different, while the tools and bridges and buildings have been created either to expand or protect the physical abilities of humans, systems information created to expand our mental capacities, to help our thinking.
Given that, the software can still be designed, but it is a different type of engineering. Software and Information Engineering as a concept has been known since the 1970s, but all who believe it is called a software engineer usually the subject of anger, contempt, or at least the provisions Disciplines and Schools of Engineering. I'm not an engineer, would not say it is one but I have understood that traditional is working on software engineering within their disciplines. In the future, as software becomes even more critical for our welfare and safety, it is possible that those who design and create software engineers will have to be accredited, as well as to design and build bridges. I History shows that first bridge and a few other structures were prone to collapse before engineering principles to prevent it. The software is only a half century age, so that even in the era of high speed Internet and change, more time will be required for the software in line with other long products.
Meanwhile, you must be a goal for all of us in the business of IT to adopt aspects of engineering tools to improve software quality, and modeling is a key concept to adopt. I'm almost afraid that many still promoting programming as an art form, the code can be beautiful or exquisite in any way. Well, even the darker arts need an audience to appreciate it, and can not be only from other artists. The software is a product to be used, not admired, so that any case, developers of the past 50 years have been more like artisans, using individual skills and experience to produce useful "objects" for society to use. The problem is that the demand follows the departure from the developer out of band (remember the delay!), Methods to improve, repeatable and transferable are needed to transform software development from a craft to a real industry.
11. Partition of major projects in three phases month, which is the key period long can plan without the possibility of a significant change of priorities, resources, etc.
I was fortunate to learn this early 90s as Project Management was to obtain a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited quantities, MS Project, for other hand, was readily available and emerging project managers thought they could now plan the world for months or years in advance. What really happened, however, remained constant re-planning as the reality of business change and resource rotation always had its effect. As Napoleon said, "A plan is only good until the battle is joined. "After that, you have to adapt to changes that will always come.
My own experience was a major project which was divided into a dozen pieces, which were planned separately to a target of 18 months away, and at that time I was asked to integrate them into one plan, while the resolution conflicts over resources. The first thing we found was that MS Project at the time it crashed when it reached about a thousand tasks.
It was then some project consultants were taken to resolve this mess, and when I first heard the above principle. Yes, you need a plan to start and control a project in time. You can even map out a plan over several months to see and communicate the big picture, but not commit to any date more than 3 months distance, most likely will miss. This also means that you must do the detailed planning for the following date only objective, namely, the plan of the complete structure (WBS) and resource allocation. (At the other end of the level of detail, IBM consultants also recommended that the child's task in the PEP should be 2 weeks, not less, otherwise they are micro-management.)
Once you have a detailed plan for three months, and a high level plan for the rest of the project can add more details with new target dates as the project progresses, as each intermediate goal is reached or a rolling basis every month. The level of change in any period 3 months will be manageable, much more than during the entire project.
A more recent corollary to the principle of three months, the age of the mega-project must be for now. Everything is a project that takes many months or years to deliver the system is doomed to failure. Yes systems, large still needed, but broken into pieces can be delivered, ideally every 3 months since that and start to slide back to the mega-project approach, while shorter than not produce enough of the system is worth to deliver to the company. All business operates in cycles of three months quarter anyway, should too.
12. Within three months phase, plot work for periods of two weeks, look for 2 weeks, and then design and develop for 2 weeks (two developers) and then try for 2 weeks. When first two weeks of analysis is done, start the next two weeks of analysis in parallel with the design / development, continue cascading two weeks until period Full project scope has been addressed.
OK, a word long paragraph 64 is pushing the boundaries of a 'principle' but this point is the basic building block of the cascade. Two periods of weeks too aggressive? I think not, based on experience. I think developers and a tester like to work in such quick bursts, such as faster delivery of results makes someone feel more productive and achieve rapid and illustrate what works and does not work. However, small pieces fast delivery must be integrated into an overall solution, which leads to Principle # 13.
13. Given many medium and small software deliverables, use architecture to manage and integrate a complete system benefits.
This is another declaration specific principle # 3, Cascade, an information system architecture used to integrate the results two weeks, to complete a Service (component, sub-system) is assembled.
In parallel, a launch schedule is a great approach to support implementation. Compile the results usable in versions planned come on-stream as a whole. According to the Principle # 11, a release of each quarter is recommended. The company receives what they are paying for frequently enough to be of value, but not enough so that the assimilation of change is so common that causes chaos.
How do these sounds? I know that some people will disagree with some of the principles (very important in some cases). Some may be concerned or disbelief enough to want more details. My intention is to publish a joint monitoring of items, one for each principle. If you want everything faster, I offer all of it in book form in lulu.com/content/2088656.
If someone wants to discuss these principles with me directly, visit me at / / sites.google.com / site / cascadethebook / and leave a comment.
About the Author
David Wright is a veteran of over 25 years in the IT trenches. He started as a programmer in the mainframe-dominated 80’s, followed by 20 years as a Business Analyst and Architect, supplemented with stints in project management and testing when limited resources required it.
Mr. Wright has spent time both in operational areas delivering enhanced and new business systems, and in research and development focusing on information system methodologies and tools. The companies he has served in these capacities have ranged from life insurance to express delivery to equipment leasing & financing. In those companies, he has supported both the operational business and supporting functions like Finance, Human Resources, and even IT administration systems.
ARGUS 300 Slide Projector
 |
 |
koada ff lens 100m/f2.8 slide projection $15.00 |
 |
Vintage Sears Projection screen 40 x 40 inches movie slide $19.99 |
 |
PROJECTION TABLE VIEWER FOR 35MM SLIDES MADE IN USA $29.99 |
 |
Kodak Ektanar C Lens 127mm f/2.8 Slide Projection H7 $14.99 |
 |
NRNU 40″ GOLD KNOX PANORAMA FILM SLIDE PROJECTION SCREEN EXC COND $35.00 |
 |
37.5″ TURQUOISE RADIANT SUPER CHAMPION II 2 FILM SLIDE PROJECTION SCREEN EXC $35.00 |
 |
Harwood ‘80′ Slide Editor Viewer Model SE-1 projection KMart pictures Kodachrome $9.00 |
 |
100 LINEAR Polarized 3D Glasses-Slide Projection-Movies $44.95 |
 |
SYLVANIA CXK SLIDE PROJECTION LAMP BULB PROJECTOR 300 W $10.00 |
 |
DAK 500W Lamp for Slide Projection $0.01 |
 |
NEW KODAK SLIDE PROJECTION EKTAGRAPHIC FF LENS 65MM F/3.5 $24.99 |
 |
NEW Kodak Ektapro 85mm Slide Projection Lens FF F/2.8 *FREE SHIPPING* $24.99 |
 |
Telex 3000 Series Model 3000Z Sestar Slide Movie Projector Projection Lens $3.99 |
 |
KODAK 4400 CAROUSEL SLIDE PROJECTOR WITH ZOOM LENS NEW BULB PROJECTION PICTURES $63.00 |
 |
ARGUS PBB 300 Projector. 35mm Slides 4″ Projection 3.5f $30.00 |
 |
Dalite Versatol Movie Slide Screen Projector Projection Screen FREE SHIP USA $53.00 |
 |
Singer Projector Movie Slide Silk Screen Projection! FREE SHIPPING USA!! $10.50 |
 |
SpongeBob Slide Show Projection Pens 35ct WHOLESALE LOT $39.99 |
 |
FILM STRIPS SLIDES AND PROJECTION EQUIPMENT FROM THE USSR 38″X26″ POSTER KNIGA $4.99 |
 |
CZA 120V 500 WATT PROJECTOR LAMP PROJECTION BULB 35mm SLIDE, 8mm 16MM Movie Film $25.00 |
 |
Buhl Overhead and Slide Projection Lamps EVW EVW-S $11.00 |
 |
Buhl Overhead and Slide Projection Lamps EHJ EHJ-S $9.00 |
 |
Buhl Overhead and Slide Projection Lamps FXL-5 $11.00 |
 |
Buhl Overhead and Slide Projection Lamps ENH ENH-S $11.00 |
 |
Buhl Overhead and Slide Projection Lamps FHS FHS-S $11.00 |
 |
WIKO Kodak Slide Projection FF Lens 4-6in f/3.5 100-150 $59.95 |
 |
Two SpongeBob Slide Show Projection Pens NEW WITH TAGS $5.99 |
 |
Two Dora The Explorer Slide Show Projection Pens NWT $4.99 |
 |
Dora The Explorer Slide Show Projection Pen 35ctDisplay $39.99 |
 |
ROWI ANTIQUE PROJECTION POINTER (SLIDES, MOVIES, PRESENTATION) $3.50 |
 |
Psychedelic Dreams Vol. 1 (Transient) $14.99 … |
 |
Composition No. 174: For Ten Percussionists, Slide Projections, Constructed Environment $9.99 … |
 |
Psychedelic Vibes 7 $19.95 … |
 |
Levolor Kirsch A7004213286 46 to 84-Inch Heavy Duty Double Curtain Rod Width, White $3.68 Heavy gauge steel, baked enamel finish. Rounded edges. White. No. R823.025: Extends 28″ to 48″ (bag) No. R825.025: Extends 48″ 86″ (bag)… |
 |
Kodak FHS Lamp $10.99 The Kodak FHS Lamp works specifically with Kodak Carousel models: 4200, 4400, 4600, 5200, 5400, and 5600. It operates at 82 volts and runs on 300 watts. This lamp generates 80 percent of the brightness of the standard Kodak Ektagraphic projector lamp. … |
 |
GE 38476 – ELH Projector Light Bulb $4.35 300 watt 120 volt MR16 2-Pin (GX5.3) Base 3,350K ELH Slide Projector / Stage / Studio GE Light Bulb… |
 |
GE 29360 – DCA Projector Light Bulb $31.78 150 watt 21 volt T12 4-Pin (GX17q) Base 3,250K DCA Slide Projector / Stage / Studio GE Light Bulb… |
 |
Logitech Professional Presenter R800 with Green Laser Pointer $56.00 Logitech Logitech R800 Presentation Remote Control 910-001350 Projector Remotes… |
 |
EPSON EX7200 Multimedia Projector (V11H367120) $499.99 With its included carrying case and versatile connectivity options, the small, lightweight Epson EX7200 3LCD WXGA Multimedia Projector is ready to go anywhere…. |
 |
GSI Quality Apple iPad Dock Connector To VGA Cable Adapter – Enjoy iPad Video And Audio On Big TV Screen Or Projector $23.99 Introducing The New Adapter Connection Kit From GSI, Designed To Put All Your Favorite Music And Visual Files Onto The Big Screen. Easy, Simple And User Friendly, It Is An Affordable Alternative To The Other Similar Models Out There…. |
Tags: art, photography, presentation, projection, projector, slide projector, slide projector bulbs, slide projector sound effect, slide projectors 35mm, slide projectors for sale
Previous Post: Kodak Blue Next Post: Leading Micro